Re: [xwiki-devs] [Contrib] xwiki-application-mailarchive
On Feb 8, 2013, at 8:55 AM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, Thanks for feedbacks ! Le 7 févr. 2013 18:53, Vincent Massol vinc...@massol.net a écrit : Hi Jeremie, I'm trying to use version 0.2. Some comments: * When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin, Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under MailArchivePrefs space, and add an object of type MailArchiveCode.ServerSettingsClass to define a server. * On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) G... :-) If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :) Imap or any protocol supported by javamail... But you're right, the app acts as a mail sniffer, and stores mails sent to configured account(s) into wiki pages. What is planned of course is an import feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course. There are different options but the simplest IMO is to parse/import mailman's mbox archive files. Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :) Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers. - http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/mbox/MboxParser.java - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/org/apache/james/mime4j/samples/mbox/IterateOverMbox.java - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/apache/labs/mboxer/MBoxTest.java Thanks -Vincent Here's the format: * http://en.wikipedia.org/wiki/Mbox * http://tools.ietf.org/html/rfc4155 Thanks -Vincent If there are other possibilities I'm missing, I'm open to any comment :-) Br, Jeremie Thanks -Vincent On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: I just tested installation from EM from xwiki.org repository, and it seems to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully. 2013/2/3 Jeremie BOUSQUET jeremie.bousq...@gmail.com Thanks Vincent ! Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While my version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case. Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion. Thanks again, Jeremie 2013/2/3 Vincent Massol vinc...@massol.net On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, 2013/2/3 Vincent Massol vinc...@massol.net Hi Jeremie, On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hello devs, Please could you promote release 0.2 of mail archive app in your nexus repository ? Cool :) Seen that you had some issues to release it? Anything we can help with? Nothing, except by me some better brains, so I don't forget my GPG passphrase next time ;-) :) groupId: org.xwiki.contrib.mailarchive artifactIds: xwiki-contrib-mail xwiki-contrib-mailarchive-api xwiki-contrib-mailarchive-ui mstor I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs? See discussion http://xwiki.markmail.org/search/?q=mstor#query:mstor+page:1+mid:owjykurnlztrxrac+state:results Basically, I need mstor library to create a Javamail store (to backup/reload emails), but this library comes with extra transitive dependencies, that
Re: [xwiki-devs] [Contrib] xwiki-application-mailarchive
On Feb 8, 2013, at 9:03 AM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 8:55 AM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, Thanks for feedbacks ! Le 7 févr. 2013 18:53, Vincent Massol vinc...@massol.net a écrit : Hi Jeremie, I'm trying to use version 0.2. Some comments: * When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin, Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under MailArchivePrefs space, and add an object of type MailArchiveCode.ServerSettingsClass to define a server. * On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) G... :-) If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :) Imap or any protocol supported by javamail... But you're right, the app acts as a mail sniffer, and stores mails sent to configured account(s) into wiki pages. What is planned of course is an import feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course. There are different options but the simplest IMO is to parse/import mailman's mbox archive files. Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :) Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers. - http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/mbox/MboxParser.java - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/org/apache/james/mime4j/samples/mbox/IterateOverMbox.java - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/apache/labs/mboxer/MBoxTest.java Example: http://ieugen.blogspot.fr/2012/06/java-mbox-parsing-with-apache-james.html Thanks -Vincent Thanks -Vincent Here's the format: * http://en.wikipedia.org/wiki/Mbox * http://tools.ietf.org/html/rfc4155 Thanks -Vincent If there are other possibilities I'm missing, I'm open to any comment :-) Br, Jeremie Thanks -Vincent On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: I just tested installation from EM from xwiki.org repository, and it seems to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully. 2013/2/3 Jeremie BOUSQUET jeremie.bousq...@gmail.com Thanks Vincent ! Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While my version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case. Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion. Thanks again, Jeremie 2013/2/3 Vincent Massol vinc...@massol.net On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, 2013/2/3 Vincent Massol vinc...@massol.net Hi Jeremie, On Feb 3, 2013, at 4:15 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hello devs, Please could you promote release 0.2 of mail archive app in your nexus repository ? Cool :) Seen that you had some issues to release it? Anything we can help with? Nothing, except by me some better brains, so I don't forget my GPG passphrase next time ;-) :) groupId: org.xwiki.contrib.mailarchive artifactIds: xwiki-contrib-mail xwiki-contrib-mailarchive-api xwiki-contrib-mailarchive-ui mstor I was about to do it when I noticed mstor. What is this? If this is a 3rd party lib why publish it with the org.xwiki.contrib.mailarchive groupid instead of using its own groupid as we do for other 3rd paty libs? See discussion
Re: [xwiki-devs] Testing some JVM Analysis Tool
On Feb 8, 2013, at 12:35 AM, Ludovic Dubost ludo...@xwiki.com wrote: Hi, I've been testing newrelic which has some interesting live JVM analysis. I've been running the JVM Profiling while running a load test going on various XWiki pages (except activity stream) including AWM, LiveTable Searches, Content pages, Lucene search and loading ressources. Here is a result of the profiling: 25.0% - java.net.SocketInputStream.socketRead0 32 Collapsed methods (show) 25.0% - com.xpn.xwiki.store.hibernate.query.HqlQueryExecutor.execute 21.0% - org.xwiki.query.internal.DefaultQueryExecutorManager.execute 11.0% - org.xwiki.query.internal.DefaultQuery.execute 127 Collapsed methods (show) 11.0% - java.lang.Thread.run 9.9% - org.xwiki.query.internal.SecureQueryExecutorManager.execute 4.2% - com.xpn.xwiki.store.hibernate.query.DefaultQueryExecutor.execute 12.0% - org.apache.velocity.runtime.parser.node.SimpleNode.render 12.0% - org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate 12.0% - org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate 8.1% - org.xwiki.rendering.internal.macro.velocity.VelocityMacro.evaluateString 4.3% - com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate 9.2% - org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate 8.5% - com.xpn.xwiki.render.DefaultVelocityManager.getVelocityEngine 4.1% - org.apache.velocity.runtime.parser.node.ASTBlock.render 4.1% - com.xpn.xwiki.web.XWikiAction.execute 3.6% - org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transformOnce 3.2% - org.apache.velocity.runtime.directive.Foreach.render 2.9% - org.xwiki.rendering.wikimodel.xwiki.xwiki21.javacc.XWikiScanner.docElements 2.8% - com.xpn.xwiki.plugin.lucene.SearchResults.getRelevantResults 2.6% - com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate 2.4% - com.mysql.jdbc.PreparedStatement.executeQuery 2.4% - org.xwiki.uiextension.internal.WikiUIExtension.getParameters 2.3% - org.xwiki.rendering.wikimodel.xwiki.xwiki21.javacc.XWikiScanner.line My understanding is that we spend 25% of time reading from the DB (this could be livetable related for instance). Around 50 in various velocity parts. Around 10% in the XWiki rendering and 3% in Lucene search. 2,4% in UI extensions (no visible rights, probably because running as Admin) Velocity is clearly quite expensive. Now I see particularly: 8.5% - com.xpn.xwiki.render.DefaultVelocityManager.getVelocityEngine Would this mean we are spending 8,5% of the time getting the velocity engine to use ? Yes, I had already noticed that. There's a synchronization done on that method that is probably costly. I'll look into it. Thanks -Vincent This sounds a lot. In any case this is food for thoughts for future optimizations. Ludovic ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Contrib] xwiki-application-mailarchive
Many thanks Vincent, that's great ! :) Actually I just checked, and the Javamail store I use (mstor) supports MBox format natively [1]. It's what I currently use to allow archiving emails on filesystem, so there's a kind of logic using it to do the reverse operation for import ... Note: you could ask why I archive mails both in xwiki pages and on FS. Idea is that in MBox format I can keep exhaustive content of emails, and be able to re-load them if necessary (migrations are a possible use-case), while in xwiki pages only a subset of email information is kept. Putting emails in the store is an option though, so it can be switched off if needed. [1] http://wiki.modularity.net.au/mstor/index.php?title=Mbox 2013/2/8 Vincent Massol vinc...@massol.net On Feb 8, 2013, at 9:03 AM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 8:55 AM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 8:17 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, Thanks for feedbacks ! Le 7 févr. 2013 18:53, Vincent Massol vinc...@massol.net a écrit : Hi Jeremie, I'm trying to use version 0.2. Some comments: * When I go to http://localhost:8080/xwiki/bin/view/MailArchive/Admin , Server's tab and click Add I get a blank page Weird, I tested that from a fresh 4.4.1 install... I'll check again. Anything noticeable from firebug / ajax request ? Anyway, workaround would be to create a page under MailArchivePrefs space, and add an object of type MailArchiveCode.ServerSettingsClass to define a server. * On http://localhost:8080/xwiki/bin/view/MailArchive/Statistics it says there are 2 posts but obviously I don't have any ;) G... :-) If we wanted to use the mailarchive app on xwiki.org to get all mails from our mailing lists, how would we set it up? It seems it needs an email account and will get emails using imap, correct? So how do we load all mailarchive emails into an email account? :) Imap or any protocol supported by javamail... But you're right, the app acts as a mail sniffer, and stores mails sent to configured account(s) into wiki pages. What is planned of course is an import feature, but it needs work. Currently I plan to allow importing mails from a .pst file if possible. Question is: if you would ask for an extract of all mails from the servers managing your xwiki mailing-lists, what would be the format ? If you have that information, I would focus the import feature to parse that format of course. There are different options but the simplest IMO is to parse/import mailman's mbox archive files. Just noticed that Tika Parsers (which we use) should be able to parse MBox files already :) Or http://james.apache.org/mime4j/ which seems to be used by Tika Parsers. - http://svn.apache.org/repos/asf/tika/trunk/tika-parsers/src/main/java/org/apache/tika/parser/mbox/MboxParser.java - http://svn.apache.org/repos/asf/james/mime4j/trunk/examples/src/main/java/org/apache/james/mime4j/samples/mbox/IterateOverMbox.java - http://svn.apache.org/repos/asf/labs/mboxer/mbox-reader/src/test/java/org/apache/labs/mboxer/MBoxTest.java Example: http://ieugen.blogspot.fr/2012/06/java-mbox-parsing-with-apache-james.html Thanks -Vincent Thanks -Vincent Here's the format: * http://en.wikipedia.org/wiki/Mbox * http://tools.ietf.org/html/rfc4155 Thanks -Vincent If there are other possibilities I'm missing, I'm open to any comment :-) Br, Jeremie Thanks -Vincent On Feb 3, 2013, at 6:30 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: I just tested installation from EM from xwiki.org repository, and it seems to install correctly :) I'll try my best not to wait so long for next version ... That one is far from perfect but should be far more usable than 0.1 thanksfully. 2013/2/3 Jeremie BOUSQUET jeremie.bousq...@gmail.com Thanks Vincent ! Maybe I'm wrong, but I didn't want to use the original groupId of this mstor artifact, because its dependencies are slightly modified compared to the original. I think it would introduce the false impression of relying on the original artifact, while it's not really the case. If someone depends on it, thinking it's the original, in a standalone environment, it might not work as expected. While my version with different transitive dependencies, is the only one that works without conflicting with XE. For these complex cases, might be nice that EM manages maven exclusions, though maybe it's a big work for not so frequent use-case. Nexus config can be somewhat tricky ;-) I know it a little but not pro features as staging and promotion. Thanks again, Jeremie 2013/2/3 Vincent Massol vinc...@massol.net On Feb 3, 2013, at 5:05 PM, Jeremie BOUSQUET jeremie.bousq...@gmail.com wrote: Hi Vincent, 2013/2/3 Vincent Massol
Re: [xwiki-devs] Testing some JVM Analysis Tool
On Fri, Feb 8, 2013 at 1:15 AM, Ludovic Dubost ludo...@xwiki.com wrote: In my previous test, the database was not very optimized. Here is the result with a more optimized mysql 5.1: Could you elaborate on what you do to optimize the databse ? JV. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] OpenFire xwiki integration?
Hi Paul, I remember that back in the summer of 2010 some XWiki developers looked at integrating a XMPP server with XWiki. If I remember correctly, a LDAP server was used for user management and both the XMPP server and the wiki were plugged into it. There was a small chat box popping up in wiki pages as well as a list of connected users from which one could initiate conversations. It was very experimental, worked fine for about 15 users but I have no idea about scaling. Thanks, Guillaume On Thu, Feb 7, 2013 at 10:43 PM, Paul Libbrecht p...@hoplahup.net wrote: Hello fellow XWiki developers, I was wondering if anyone had taken the time to have a joint install of XWiki and OpenFire, apparently a fairly scalable XMPP server with nice feature completeness. Something should be done at the UI level, such as candy-chat probably. My question is more about the server side, there seems to be a way to write an adapter to fetch user-information from a database, so that exposing users of XWiki might be simple. Did anyone try this already? Did it scale? thanks in advance paul ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Feb 7, 2013, at 5:52 PM, Vincent Massol vinc...@massol.net wrote: FWIW Guava is using a @Beta annotation: http://code.google.com/p/guava-libraries/ Extract: APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, in any major release. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard). Here is a current list of all the beta APIs. Serialized forms of ALL objects are subject to change. Do not persist these and assume they can be read by a future version of the library. Deprecated non-beta APIs will be removed eighteen months after the release in which they are first deprecated. You must fix your usages before this time. If you don't, any manner of breakage might result (you are not guaranteed a compilation error). Interestingly a user points out the issue I had with using an annotation, see the comments in http://code.google.com/p/guava-libraries/wiki/Release10: Extract: My understandig of @Beta is, that these are the higly unstable parts of guava, so I don't want to use them (and I guess most developers don't want to because why should anybody make his lives more difficult when moving to the next version). But how do I do that? I don't want to look all the time at the source code when programming to make sure I didn't use the beta parts. Code completion knows nothing about @Beta (and it shouldn't!). Hence I have to remove all the beta parts. But why should the user handle the repackaging thing when you can simple release two versions: a beta / instable version and a stable / release version. Simple as that. Anybody can use the version he likes. Other OSS projects handle this much better. The same goes vor versioning, naming, packaging, downloading, etc. E. g. I never had such fruitless discussions with Apache software (and in case Apache commons collection ever releases a generified version, I'll most certainly switch back to that). Thanks -Vincent Thanks -Vincent On May 3, 2012, at 9:47 AM, Vincent Massol vinc...@massol.net wrote: Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s). This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for young APIs that are not considered stable. Proposal 1: Internal package = * Young APIs must be located in the internal package till they become stable. I propose internal to reuse an existing package that we filter when testing for CLIRR. internal means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from internal to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy. * If we want to add a new method to an existing public API then this should not be considered a young API. It's just an addition to an existing API and thus goes directly to the deprecation/legacy cycle. * We need to be careful to isolate young APIs from public API so that users don't inadvertently use young unstable APIs by mistake. If not possible then directly go through the deprecation/legacy cycle. The advantage of this proposal is that it doesn't change our current practices and is very easy to verify through CLIRR. Proposal 2: Experimental package = Another possibility I can think of is to introduce a new experimental package instead of reusing the internal one. It has the advantage of being able to follow young APIs and ensure they don't stay in that state indefinitely, while still allowing the user who uses it to notice it's experimental. Proposal 3: Experimental Annotation = Another idea is to just use an @Experimental javadoc tag for experimental code. It has the advantage of using the target package but it has drawbacks: * It's impossible for users to notice that they're using Experimental APIs since when they import a class they won't see anything that'll tell them they're using a young API * It's almost impossible to tell CLIRR to exclude those APIs from its checks. The only way to do this is to modify the source code of the CLIRR plugin AFAIK. Thus we would need to exclude those manually using CLIRR excludes and thus
Re: [xwiki-devs] [VOTE] Get rid of Portlet API in oldcore
Nobody seems to be against it, done. On Thu, Feb 7, 2013 at 4:48 PM, Thomas Mortagne thomas.morta...@xwiki.com wrote: Hi guys, oldcore contains references to Portlet API 1.0 in various API. There is several issues: 1) Thoses API are useless since most of the code expect a servlet and would never work inside a Portlet so that make this API totally useless 2) It's a real pain for things like https://github.com/xwiki-contrib/sandbox/tree/master/xwiki-portlet (a portlet proxy/translator in front of XWiki) since it makes impossible to use Portlet API 2.0 (we had to create our own special branch were we remove all reference to 1.0 API in oldcore) 3) XWiki cannot work without the portlet jar even when used as Servlet which is quite ugly Since we are starting a new major version and it's a breaking change I propose to do it now. Here is my +1 -- Thomas Mortagne -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Feb 8, 2013, at 11:18 AM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 5:52 PM, Vincent Massol vinc...@massol.net wrote: FWIW Guava is using a @Beta annotation: http://code.google.com/p/guava-libraries/ Extract: APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, in any major release. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard). Here is a current list of all the beta APIs. Serialized forms of ALL objects are subject to change. Do not persist these and assume they can be read by a future version of the library. Deprecated non-beta APIs will be removed eighteen months after the release in which they are first deprecated. You must fix your usages before this time. If you don't, any manner of breakage might result (you are not guaranteed a compilation error). Interestingly a user points out the issue I had with using an annotation, see the comments in http://code.google.com/p/guava-libraries/wiki/Release10: Extract: My understandig of @Beta is, that these are the higly unstable parts of guava, so I don't want to use them (and I guess most developers don't want to because why should anybody make his lives more difficult when moving to the next version). But how do I do that? I don't want to look all the time at the source code when programming to make sure I didn't use the beta parts. Code completion knows nothing about @Beta (and it shouldn't!). Hence I have to remove all the beta parts. But why should the user handle the repackaging thing when you can simple release two versions: a beta / instable version and a stable / release version. Simple as that. Anybody can use the version he likes. Other OSS projects handle this much better. The same goes vor versioning, naming, packaging, downloading, etc. E. g. I never had such fruitless discussions with Apache software (and in case Apache commons collection ever releases a generified version, I'll most certainly switch back to that). Actually, reading further it seems only one user has an issue with the @Beta annotation and others find it acceptable. ok so here's the summary of the brainstorming so far: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) Note that with proposal 3 we also need to remember 2 things: - we'll need to add CLIRR excludes but that can be done globally using the global exclude so not too painful - we'll need to detail how long is the @Beta annotation supposed to stay. If it stays forever it's the same syndrome as never releasing a 1.0 version which doesn't help because people will use it in production anyway if it's too long to be 1.0. So proposal 3 needs to have a max timeframe. IMO a full cycle would be a good max time to remain @Beta annotations. So if you add the @Beta in version N.P we have to remove it before N+2.0 (in practice that's a max time of 1.5 years). We could also say N+1.P but it's harder to remember since it means verifying at each release whereas N+1.P means verifying only once. Personally I'm ok to try option 3 since I'd like to make progress on this. WDYT? Thanks -Vincent Thanks -Vincent Thanks -Vincent On May 3, 2012, at 9:47 AM, Vincent Massol vinc...@massol.net wrote: Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s). This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for young APIs that are not considered stable. Proposal 1: Internal package = * Young APIs must be located in the internal package till they become stable. I propose internal to reuse an existing package that we filter when testing for CLIRR. internal means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from internal to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of deprecation/legacy. * If we want to add a new method to an existing public API then this should not be
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Fri, Feb 8, 2013 at 11:42 AM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 11:18 AM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 5:52 PM, Vincent Massol vinc...@massol.net wrote: FWIW Guava is using a @Beta annotation: http://code.google.com/p/guava-libraries/ Extract: APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, in any major release. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard). Here is a current list of all the beta APIs. Serialized forms of ALL objects are subject to change. Do not persist these and assume they can be read by a future version of the library. Deprecated non-beta APIs will be removed eighteen months after the release in which they are first deprecated. You must fix your usages before this time. If you don't, any manner of breakage might result (you are not guaranteed a compilation error). Interestingly a user points out the issue I had with using an annotation, see the comments in http://code.google.com/p/guava-libraries/wiki/Release10: Extract: My understandig of @Beta is, that these are the higly unstable parts of guava, so I don't want to use them (and I guess most developers don't want to because why should anybody make his lives more difficult when moving to the next version). But how do I do that? I don't want to look all the time at the source code when programming to make sure I didn't use the beta parts. Code completion knows nothing about @Beta (and it shouldn't!). Hence I have to remove all the beta parts. But why should the user handle the repackaging thing when you can simple release two versions: a beta / instable version and a stable / release version. Simple as that. Anybody can use the version he likes. Other OSS projects handle this much better. The same goes vor versioning, naming, packaging, downloading, etc. E. g. I never had such fruitless discussions with Apache software (and in case Apache commons collection ever releases a generified version, I'll most certainly switch back to that). Actually, reading further it seems only one user has an issue with the @Beta annotation and others find it acceptable. ok so here's the summary of the brainstorming so far: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) Note that with proposal 3 we also need to remember 2 things: - we'll need to add CLIRR excludes but that can be done globally using the global exclude so not too painful - we'll need to detail how long is the @Beta annotation supposed to stay. If it stays forever it's the same syndrome as never releasing a 1.0 version which doesn't help because people will use it in production anyway if it's too long to be 1.0. So proposal 3 needs to have a max timeframe. IMO a full cycle would be a good max time to remain @Beta annotations. So if you add the @Beta in version N.P we have to remove it before N+2.0 (in practice that's a max time of 1.5 years). We could also say N+1.P but it's harder to remember since it means verifying at each release whereas N+1.P means verifying only once. Personally I'm ok to try option 3 since I'd like to make progress on this. WDYT? Ok for me. Thanks -Vincent Thanks -Vincent Thanks -Vincent On May 3, 2012, at 9:47 AM, Vincent Massol vinc...@massol.net wrote: Hi devs, We have recently voted a rule where we said that we will do the following: * Always deprecate APIs * Always move them to Legacy modules * And when there's a technical issue to moving stuff to the Legacy module, only then, send a VOTE to remove an API (see http://markmail.org/message/tino4ngttflc5i3s). This means that from now on (starting on 26th of April 2012) we're not allowed to put excludes in CLIRR. However I've seen that we have added some CLIRR excludes after the vote was passed. I believe that the main issue we have is for young APIs that are not considered stable. Proposal 1: Internal package = * Young APIs must be located in the internal package till they become stable. I propose internal to reuse an existing package that we filter when testing for CLIRR. internal means that users should not use this API because it's considered unstable and can change at any time. * When a Young API is considered stable enough and we want to open it to public consumption then we move it from internal to its target package (that's easy to with IDEs). From that point forward any changes to them goes through the standard mechanism of
[xwiki-devs] [Contrib] Classification Extension
Hi devs, I would need a contrib repo for an extension I've developped for USH. It is called Classification and enables to create easily a classification plan with categories and sub-categories. Apparently such a feature is often needed on client project, so I hope it could be useful. Thanks, Thomas ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Contrib] Classification Extension
On Feb 8, 2013, at 11:49 AM, Thomas Delafosse thomas.delafo...@xwiki.com wrote: Hi devs, I would need a contrib repo for an extension I've developped for USH. It is called Classification and enables to create easily a classification plan with categories and sub-categories. Apparently such a feature is often needed on client project, so I hope it could be useful. Done: https://github.com/xwiki-contrib/application-classification Also created the mail module that you asked for in some other thread: https://github.com/xwiki-contrib/xwiki-platform-mail This module is meant to contain the future platform mail module, see: http://markmail.org/thread/pfoyi4qeqvlc75yo Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Contrib] Classification Extension
How is this different than the parent-child page system? paul On 8 févr. 2013, at 12:49, Thomas Delafosse wrote: I would need a contrib repo for an extension I've developped for USH. It is called Classification and enables to create easily a classification plan with categories and sub-categories. Apparently such a feature is often needed on client project, so I hope it could be useful. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Contrib] Classification Extension
It is based on the parent-child page system, but pages/categories thus created also contains an object marking them as part of a special hierarchy, so it's a bit stronger than just the parent-child relation. This extension also provides some livetables to see each sub-category of a given category. So, it's nothing revolutionary, it just makes it easier to create special hierarchies. Thomas On Fri, Feb 8, 2013 at 12:06 PM, Paul Libbrecht p...@hoplahup.net wrote: How is this different than the parent-child page system? paul On 8 févr. 2013, at 12:49, Thomas Delafosse wrote: I would need a contrib repo for an extension I've developped for USH. It is called Classification and enables to create easily a classification plan with categories and sub-categories. Apparently such a feature is often needed on client project, so I hope it could be useful. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] Testing some JVM Analysis Tool
Some bigger settings for a few things. The test is on innodb and I believe this setting is the most important: innodb_buffer_pool_size=512M But the cache size also might have an effect. I think it was either low or turned off before. key_buffer = 32M query_cache_limit = 1M query_cache_size= 32M query_cache_type= 1 innodb_buffer_pool_size=512M innodb_additional_mem_pool_size = 2M We plan to do more testing to know exactly what is important. Ludovic 2013/2/8 Jean-Vincent Drean j...@xwiki.com On Fri, Feb 8, 2013 at 1:15 AM, Ludovic Dubost ludo...@xwiki.com wrote: In my previous test, the database was not very optimized. Here is the result with a more optimized mysql 5.1: Could you elaborate on what you do to optimize the databse ? JV. ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] XWiki Flavors
On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 5:38 PM, Eduard Moraru enygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol vinc...@massol.net wrote: Hi Caty, On Feb 7, 2013, at 5:08 PM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. Indeed. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. Some thoughts: * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called flavor since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that I agree with this. IMO, we should bring back the idea of extension types (including this new flavour type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the maven packaging element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for POM or create a new Maven packaging but that's probably unnecessary, supporting POM is enough. What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. Thanks, Eduard Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup. Thanks -Vincent Thanks, Eduard * Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes * Re the base package there's no need to have one since extensions declare their require dependencies http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Sounds good. Thanks -Vincent Just some ideas. Thanks, Caty [1] [Idea]Community flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] XWiki Flavors
On Feb 8, 2013, at 1:39 PM, Eduard Moraru enygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol vinc...@massol.net wrote: On Feb 7, 2013, at 5:38 PM, Eduard Moraru enygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol vinc...@massol.net wrote: Hi Caty, On Feb 7, 2013, at 5:08 PM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. Indeed. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. Some thoughts: * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called flavor since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that I agree with this. IMO, we should bring back the idea of extension types (including this new flavour type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the maven packaging element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for POM or create a new Maven packaging but that's probably unnecessary, supporting POM is enough. What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. I think type and category are 2 separate things. For category I was thinking about just using the existing tag feature and making that visible in the EM UI. WDYT? Thanks -Vincent Thanks, Eduard Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup. Thanks -Vincent Thanks, Eduard * Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes * Re the base package there's no need to have one since extensions declare their require dependencies http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Sounds good. Thanks -Vincent Just some ideas. Thanks, Caty [1] [Idea]Community flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
+1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
Yes it's more clear than beta. On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle d...@softec.lu wrote: +1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
By the way, if we agree on @unstable, I also think having another annotation for marking stable API that are not considered to be stable SPI. Why not something like @onlyAPI or @unstableSPI on an interface ? On Fri, Feb 8, 2013 at 3:30 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Yes it's more clear than beta. On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle d...@softec.lu wrote: +1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Feb 8, 2013, at 3:42 PM, Denis Gervalle d...@softec.lu wrote: By the way, if we agree on @unstable, I also think having another annotation for marking stable API that are not considered to be stable SPI. Why not something like @onlyAPI or @unstableSPI on an interface ? I think first we need to define what is an SPI and what is an API first. ATM I don't think I understand clearly the difference in the context of XWiki. Is it clear for you? Thanks -Vincent On Fri, Feb 8, 2013 at 3:30 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Yes it's more clear than beta. On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle d...@softec.lu wrote: +1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] OpenFire xwiki integration?
Which UI is used? thanks paul On 8 févr. 2013, at 16:34, Denis Gervalle wrote: Paul, You may want to have a look at https://github.com/xwiki-contrib/xwiki-platform-chat. It does not use OpenFire but Vysper. The way it goes for authentication is far from perfect, but it works. Regards, On Fri, Feb 8, 2013 at 11:02 AM, Guillaume Lerouge guilla...@xwiki.comwrote: Hi Paul, I remember that back in the summer of 2010 some XWiki developers looked at integrating a XMPP server with XWiki. If I remember correctly, a LDAP server was used for user management and both the XMPP server and the wiki were plugged into it. There was a small chat box popping up in wiki pages as well as a list of connected users from which one could initiate conversations. It was very experimental, worked fine for about 15 users but I have no idea about scaling. Thanks, Guillaume On Thu, Feb 7, 2013 at 10:43 PM, Paul Libbrecht p...@hoplahup.net wrote: Hello fellow XWiki developers, I was wondering if anyone had taken the time to have a joint install of XWiki and OpenFire, apparently a fairly scalable XMPP server with nice feature completeness. Something should be done at the UI level, such as candy-chat probably. My question is more about the server side, there seems to be a way to write an adapter to fetch user-information from a database, so that exposing users of XWiki might be simple. Did anyone try this already? Did it scale? thanks in advance paul ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] OpenFire xwiki integration?
On 02/08/2013 11:02 AM, Guillaume Lerouge wrote: Hi Paul, I remember that back in the summer of 2010 some XWiki developers looked at integrating a XMPP server with XWiki. If I remember correctly, a LDAP server was used for user management and both the XMPP server and the wiki were plugged into it. We were using an external OpenFire, which used an LDAP auth, the same that XWiki was using. Thus, there were the same users, but not the wiki users but the LDAP ones. Because of that, at least during the hackathon, we didn't manage to automatically log in people to the chat when they were logged in in the wiki, even if they were, actually, the same users (the user had to retype pass). There was a small chat box popping up in wiki pages as well as a list of connected users from which one could initiate conversations. It was very experimental, worked fine for about 15 users but I have no idea about scaling. I forgot the name of the js lib we used for UI, there was a little js API for communicating with an XMPP, one I had seen at a fosdem a few years ago. I can dig for that code to check it out if you want. Happy XWiki-ing, Anca Thanks, Guillaume On Thu, Feb 7, 2013 at 10:43 PM, Paul Libbrechtp...@hoplahup.net wrote: Hello fellow XWiki developers, I was wondering if anyone had taken the time to have a joint install of XWiki and OpenFire, apparently a fairly scalable XMPP server with nice feature completeness. Something should be done at the UI level, such as candy-chat probably. My question is more about the server side, there seems to be a way to write an adapter to fetch user-information from a database, so that exposing users of XWiki might be simple. Did anyone try this already? Did it scale? thanks in advance paul ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] XWiki Flavors
On 02/08/2013 02:32 PM, Vincent Massol wrote: On Feb 8, 2013, at 1:39 PM, Eduard Moraruenygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massolvinc...@massol.net wrote: On Feb 7, 2013, at 5:38 PM, Eduard Moraruenygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massolvinc...@massol.net wrote: Hi Caty, On Feb 7, 2013, at 5:08 PM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. Indeed. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. Some thoughts: * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called flavor since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that I agree with this. IMO, we should bring back the idea of extension types (including this new flavour type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the mavenpackaging element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for POM or create a new Maven packaging but that's probably unnecessary, supporting POM is enough. What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. I think type and category are 2 separate things. For category I was thinking about just using the existing tag feature and making that visible in the EM UI. Hm, but we have that, no? a beautiful tagcloud on top of the extensions livetable on the main page. The only issue is that tags UI is by default on the bottom of the page, and for extension authors it's not really straightforward to go there and fill in the tags. Maybe if we put a warning in edit mode or something, to tell people to not forget to add tags so that the tags are easier to discover. Anca WDYT? Thanks -Vincent Thanks, Eduard Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup. Thanks -Vincent Thanks, Eduard * Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes * Re the base package there's no need to have one since extensions declare their require dependencies http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Sounds good.
Re: [xwiki-devs] [Brainstorming] XWiki Flavors
On Feb 8, 2013, at 5:42 PM, Anca Luca lu...@xwiki.com wrote: On 02/08/2013 02:32 PM, Vincent Massol wrote: On Feb 8, 2013, at 1:39 PM, Eduard Moraruenygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massolvinc...@massol.net wrote: On Feb 7, 2013, at 5:38 PM, Eduard Moraruenygma2...@gmail.com wrote: On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massolvinc...@massol.net wrote: Hi Caty, On Feb 7, 2013, at 5:08 PM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/customizedInstall.png Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. Indeed. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. Some thoughts: * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called flavor since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that I agree with this. IMO, we should bring back the idea of extension types (including this new flavour type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the mavenpackaging element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for POM or create a new Maven packaging but that's probably unnecessary, supporting POM is enough. What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. I think type and category are 2 separate things. For category I was thinking about just using the existing tag feature and making that visible in the EM UI. Hm, but we have that, no? a beautiful tagcloud on top of the extensions livetable on the main page. Not in the EM UI. We have it in the Repository app UI. Thanks -Vincent The only issue is that tags UI is by default on the bottom of the page, and for extension authors it's not really straightforward to go there and fill in the tags. Maybe if we put a warning in edit mode or something, to tell people to not forget to add tags so that the tags are easier to discover. Anca WDYT? Thanks -Vincent Thanks, Eduard Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup. Thanks -Vincent Thanks, Eduard * Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes * Re the base package there's no need to have one since extensions declare their require dependencies http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreator.png If Application Within Minutes let's you create your own applications, the Flavor
Re: [xwiki-devs] JIRA cleanup for missing fixversion
On Jan 7, 2013, at 4:56 PM, Ecaterina Moraru (Valica) vali...@gmail.com wrote: For the XOFFICE we could put the next release version as fixfor. The problem is that I don't seem to have the rights to edit the closed issues. Vincent, do you need the fixfor field marked for statistics? Yes but also for release notes. It's also good to save this filter and be able to run it from time to time to check that we haven't missed any fix for. If the list already returns a lot of issues it's hard to see if any new ones are missing fix for values. Thanks -Vincent Thanks, Caty On Mon, Jan 7, 2013 at 4:30 PM, Marius Dumitru Florea mariusdumitru.flo...@xwiki.com wrote: There are a lot for XOFFICE (Florin?) and XINFRA (where we don't have releases) Thanks, Marius On Thu, Dec 27, 2012 at 9:59 AM, Vincent Massol vinc...@massol.net wrote: Hi guys, Can you help me fix all those issues that are missing fixfor? http://jira.xwiki.org/secure/IssueNavigator.jspa?reset=truejqlQuery=status+%3D+%22Closed%22+and+fixVersion+is+empty+and+category+in+%28%22Top+Level+Projects%22%29+and+resolution+%3D+%22Fixed%22 Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Feb 8, 2013, at 7:09 PM, Denis Gervalle d...@softec.lu wrote: On Fri, Feb 8, 2013 at 3:58 PM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 3:42 PM, Denis Gervalle d...@softec.lu wrote: By the way, if we agree on @unstable, I also think having another annotation for marking stable API that are not considered to be stable SPI. Why not something like @onlyAPI or @unstableSPI on an interface ? I think first we need to define what is an SPI and what is an API first. ATM I don't think I understand clearly the difference in the context of XWiki. Is it clear for you? I do not really understand your question. The general definition is rather clear: Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party. All our component interfaces are meant to be implemented by 3rd parties to override default behaviors. Are they SPI? What I would like to be annotated is API that we do not consider stable SPI at the moment. It is less restrictive than @unstable, but more than not saying anything. Is that answering your question ? That seems complex. Why not use @unstable on SPI classes/methods? Thanks -Vincent Thanks -Vincent On Fri, Feb 8, 2013 at 3:30 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Yes it's more clear than beta. On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle d...@softec.lu wrote: +1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Brainstorming] Handling young APIs for backward compatibility
On Fri, Feb 8, 2013 at 7:15 PM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 7:09 PM, Denis Gervalle d...@softec.lu wrote: On Fri, Feb 8, 2013 at 3:58 PM, Vincent Massol vinc...@massol.net wrote: On Feb 8, 2013, at 3:42 PM, Denis Gervalle d...@softec.lu wrote: By the way, if we agree on @unstable, I also think having another annotation for marking stable API that are not considered to be stable SPI. Why not something like @onlyAPI or @unstableSPI on an interface ? I think first we need to define what is an SPI and what is an API first. ATM I don't think I understand clearly the difference in the context of XWiki. Is it clear for you? I do not really understand your question. The general definition is rather clear: Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party. All our component interfaces are meant to be implemented by 3rd parties to override default behaviors. Are they SPI? If you consider them stable enough, these could be. The distinction is clearly based of what we think of it. Let me take an example: interface DataMigrationManager (do not mixup with DataMigration which is an SPI for sure). Currently, I consider this one as an API, but I do not imagine any serious usage of it as an SPI for a third party. Marking it API only, would clearly state this point of view. It means that adding a new method to this interface is not considered a breakage. Anyone which would implement it, knows it could have his code broken later. What I would like to be annotated is API that we do not consider stable SPI at the moment. It is less restrictive than @unstable, but more than not saying anything. Is that answering your question ? That seems complex. Why not use @unstable on SPI classes/methods? Because the status is about the interface as a whole. It is particularly about adding new methods (or signatures of existing methods), while existing methods are stable. I do not want to add something new, but to state clearly what we think of our interfaces. This is already the case, while we do not really state it. Considering anything an SPI is not an option IMO, since it will create more complexity over time, for a very low benefit, since the chances of a third party to implement an interface like the DataMigrationManager is near zero. And if any, this third party will surely agree to apply some minor changes to its implementation when needed. All that said, I wonder if it wouldn't be better to annotate SPI interface in place of non-SPI one, with a @SPI annotation. Which will favor API only and limit complexity. A user really interested in implementing a not annotated interface could easily open an issue explaining his use case, so we may open the interface as an SPI. Thanks -Vincent Thanks -Vincent On Fri, Feb 8, 2013 at 3:30 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: Yes it's more clear than beta. On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle d...@softec.lu wrote: +1, but I have the impression that @unstable would be more meaningful On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne thomas.morta...@xwiki.comwrote: On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol vinc...@massol.net wrote: Hi Paul, On Feb 8, 2013, at 1:22 PM, Paul Libbrecht p...@hoplahup.net wrote: Doesn't the @deprecated annotation actually does exactly the job? (except it has to be interpreted as meaning something else than old code, but do not use code). @Deprecated means something different. It's about some code that you shouldn't use because we no longer think it's good to use and it's going to be removed in the future. This is not what a @beta or @experimental annotation would mean. They would mean this is a new api that you can use but it's not stable yet and may change in the future so be prepared to update your code if that happens. Plus @deprecated is technically pretty stable API while @beta can be broken anytime. Thanks -Vincent paul On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: * Proposal 1 (internal package): - Vincent - Marius * Proposal 2 (experimental package) - Caleb * Proposal 3 (@Beta/@Experimental annotation) - Thomas - Edy * Other proposal - Denis (use 1) for small changes and only use RN to mark new module as experimental) ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] OpenFire xwiki integration?
On 8 févr. 2013, at 18:00, Anca Luca wrote: I forgot the name of the js lib we used for UI, there was a little js API for communicating with an XMPP, one I had seen at a fosdem a few years ago. I can dig for that code to check it out if you want. http://candy-chat.github.com/candy/ sounds very mature for this. I would not use LDAP for integration but probably write a custom, db-exploiting, authenticator (there's a JDBC-one currently, but it seems to want to list users) together with something in the cookie in a servlet filter (for auto-login). All non-trivial. But it seems that the UI might be rather sturdy and full-featured... hence my question to Denis. Paul ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Re: [xwiki-devs] [Proposal] Roadmap for XWiki 5.0
Hi everyone, I've created the roadmap page at http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome Could you please all check the TODOs that are marked on this page and resolve them? This entails creating the jira issues for 5.0, assigning yourself and setting the fix for on the issues. Thanks a lot -Vincent On Feb 2, 2013, at 4:55 PM, Vincent Massol vinc...@massol.net wrote: Hi devs, With XWiki 4.x cycle coming to an end soon, it's time to prepare the roadmap for XWiki 5.0. This is a proposal that comes from some internal meetings done with XWiki committers who are working for XWiki SAS. If you're interesting in participating to this release, don't hesitate to add yourself to the list so that everyone can have some visibility of what's going to be worked on during this timeframe! If you think some work defined below doesn't go in the interest of the project also feel free to raise issues. Features: * Continue SOLR implementation - Edy * EM upgrade of subwikis + flavor concept (add Flavor type in EM/Repository) + leftover from 4.x for EM/DW - Thomas + Marius for DW UI part for flavors * AWM work from 4.x to finish (see http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome) - Marius * scalable import/export - Thomas * Home page improvements (XE) and usability improvements in general - JV * Horizontal Menu management (add, remove pages) - JV * virtual=1 by default - Edy (Edy will need to make a proposal for that since it's an important decision ;)) * l10n speed improvements - Ludovic Important JIRAs sorted by priority (most important first): * AWM Add the ability to publish an application as an extension XWIKI-7377 - Marius * AWM Add the ability to export an applicationXWIKI-7376 - Marius * Unable to edit a page using the WYGIWYG editor after adding a dashboard macro to it XWIKI-8495 - Need volunteer * Improve AWM for it to deal with error messages made by Client when filling the AWM form in using special chars XWIKI-8763 - Marius * Import of Office file breaks Activity Stream and Recently Modified Panel XRENDERING-261 - Need volunteer * Cannot change document title from inline mode XWIKI-7905 - Not sure if we want it, to be checked with Marius * When the workspace owner is changed, the new owner is not added as a member nor in the admin group XWIKI-8397 - Edy * Unable to upload a new attachment using the All pages tab in the WYSIWYG editor XWIKI-8465 - Marius * Workspace owner and initial members not set as members (nor in admin group) when the workspace identifier contains an underscoreXWIKI-8394 - Edy Investigations: * XEM Homepage / Portal - Caty * Knowledge base Flavor - Caty/Ludovic * New Activity Stream Investigation Part 1 - JV (he's agree to become our AS champion :)) * General Flavours Investigation - Caty + input from tech Regarding dates I'm proposing the following: * 5.0M1: 4 March 2013 * 5.0M2: 25 March 2013 * 5.0RC1: 8 April 2013 * 5.0Final: 15 April 2013 Thanks -Vincent ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
