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

[xwiki-devs] [Proposal] Remove hardcoded version to their parent dependency in every submodule

by Bogdan Flueras

Currently all xwiki-platform submodules have in their pom.xml definition the following: <parent> <groupId>org.xwiki.platform</groupId> <artifactId>xwiki-platform-...</artifactId> <version>3.5-SNAPSHOT</version> </parent> The problem I see is that the parent version is a hardcoded in every submodule, thus making some some tasks very very difficult. This is because Maven cannot read a placeholder value placed inside <version> tag. There seems to be some work on behalf of Maven guys for this issue: http://jira.codehaus.org/browse/MNG-624 but ... My proposal is to either: 1) remove the <version> tag in the parent definition from every child module and let inheritance do it's job 2) use the <relativePath> *if the child can have access to it's parent pom by relative path* I haven't tested yet but if you remove it, will the sub module know from which parent (which could have many versions) to inherit the <version> property? WDYT? ing. Bogdan Flueras Tel: +33666116067

13 years, 6 months

3
2
0 0

[xwiki-devs] [proposal] Make filesystem attachments use permanent storage directory instead of work dir.

by Caleb James DeLisle

Hi, I'd like to switch filesystem attachments to begin using the persistent storage directory now instead of the work directory. This means there's a new way of calculating where the attachments will be stored so it might fail on upgrade. I would like to not do any migration and just add to the release notes because: #1, it doesn't cause any permanent harm so long as nobody adds attachments while it's in what is an obviously broken state. #2 administrators who have FS attachments enabled are probably going to know what's going on. #3 migration code is scary, it requires lots of work and lots of review and even if it works, people might feel violated having files shuffled around on their system without their permission. WDYT? Caleb

13 years, 6 months

4
8
0 0

[xwiki-devs] [Proposal] Generating Jenkins Jobs automatically

by Vincent Massol

Hi devs, I've been working on Jenkins Job generation (see http://jira.xwiki.org/jira/browse/XCOMMONS-87). The idea is to have a maven project that you run and which generates Jenkins Job automatically and sets them on ci.xwiki.org The pros are: * Easy to create new jobs whenever we create a new branch * Allows to manager our Jenkins configuration by storing it in our SCM Proposal 1 ========= xwiki-commons/xwiki-commons-tools/ |_ xwiki-commons-tool-jenkins/ |_ xwiki-commons-tool-jenkins-base/ |_ xwiki-commons-tool-jenkins-commons/ <-- parent = xwiki-commons-tool-jenkins-base xwiki-rendering/xwiki-rendering-tools/ |_ xwiki-rendering-tool-jenkins/ <-- parent = xwiki-commons-tool-jenkins-base xwiki-platform/xwiki-platform-tools/ |_ xwiki-platform-tool-jenkins/ <-- parent = xwiki-commons-tool-jenkins-base xwiki-enterprise/xwiki-enterprise-tools/ |_ xwiki-enterprise-tool-jenkins/ <-- parent = xwiki-commons-tool-jenkins-base xwiki-manager/xwiki-manager-tools/ |_ xwiki-manager-tool-jenkins/ <-- parent = xwiki-commons-tool-jenkins-base To run them, you go in each of the top level project's tool directory and run "mvn deploy". It creates and deploys the Jenkins Job, updating the jobs if they already exist. Proposal 2 ========= Create a new Git repository called xwiki-jenkins in https://github.com/organizations/xwiki Have a single pom.xml in there which generates all Jenkins jobs (it's possible to have various profiles if we want to generate jobs only for a subset of modules). You run it using "mvn deploy" too. Proposal 3 ========= Extends Proposal 2 but merges with the repo currently named "xwiki-debug-eclipse" . That repo would be renamed to "xwiki-tooling" or "xwiki-development-tools" or simply "xwiki-tools" and would have 2 directories at the top: xwiki-debug-eclipse/ xwiki-jenkins/ Note that both xwiki-debug-eclipse and xwiki-jenkins should follow the same version and be in sync with the other top level repositories since they're tools for a given version of commons/rendering/platform/xe/manager. If they're together it means they'll share the same JIRA project and will use 2 components to differentiate them, which is perfectly fine. Conclusion ========= I think I'm tempted a bit more by Proposal 2 and 3 because: * It allows to generate all jobs in one go * Jenkins is not really related to the rest of the build and thus it's not completely "normal" that its config should be mixed with building the runtime. For example when we deploy XWiki Commons to Maven Central it means users will see the Jenkins config there too with stuff that are only valid for xwiki.org. * It makes simpler for maintenance to have it all in one POM together. I'm undecided between Proposal 2 and 3. WDYT? Thanks -Vincent

13 years, 7 months

3
2
0 0

[xwiki-devs] New Xwiki howto guides - documentation project

by Kaya Saman

Hello, I've created some howto's over time with the latest last night..... Here are the URLs: http://dev.xwiki.org/xwiki/bin/view/Drafts/BSD_Migration http://dev.xwiki.org/xwiki/bin/view/Drafts/BSD_Install http://dev.xwiki.org/xwiki/bin/view/Drafts/Glassfish_Solaris Could I get some feedback of peoples opinions on these and **if** they're ready/good-enough to be put onto the main Xwiki site..... --if so then where they should go! Many thanks :-) Regards, Kaya

13 years, 7 months

2
1
0 0

[xwiki-devs] Activity Stream Logic

by Ludovic Dubost

Hi, I've looked a bit at the activity stream performance while looking for the performance issue since 3.2+ (http://jira.xwiki.org/browse/XWIKI-7520). Beyond this issue, I've been a bit puzzled by the logic of the activity stream implementation. Right now it seems the activity stream is generating many many queries on the base data stored in the activity stream. However I've not been able to identify the exact logic it is following as it seems to be quite complex. The whole point of the activity stream when it was initially implemented was to move the work at saving time instead of having the work at display time. As the feature got more complex it seems we move away from that solution and now we have again a huge amount of work at display time. Now maybe the actual logic of what we want to display requires this, or maybe not and we haven't gone in the right direction to implement this. I think before we reimplement the activity stream in Java as I've seen said in the feature survey, we should put the actual feature and logic on paper and make sure we are going the right way. Because otherwise reimplementing in Java won't solve anything. I think it would be really good to go back to the initial objective of having the effort at save time and then having the display only read data in display it with simple templating. Is there any documentation about the feature itself and about the logic ? Can we put somebody on writing down the logic and then discussing that it's the right thing to do ? I can help on this if I'm given some more information about why it was done the way it's done now. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 7 months

3
3
0 0

[xwiki-devs] database schema and queries

by Ricardo.Julio.Rodriguez.Fernandez＠sergas.es

Hi everybody! I'm struggling to undestand how a relational schema can be used for representing XWiki datamodel. Please, does make sense to try to describe the relational schema under XWiki data model by using a "classical" ERR diagram that uses, for instance UML for relationship notation? Is possible to rewrite using SQL any HQL or XWQL query? Thanks for your help! Ricardo -- Ricardo Rodríguez Research Management and Promotion Technician Health Research Institute of Santiago de Compostela (IDIS) http://www.idisantiago.es Nota: A información contida nesta mensaxe e os seus posibles documentos adxuntos é privada e confidencial e está dirixida únicamente ó seu destinatario/a. Se vostede non é o/a destinatario/a orixinal desta mensaxe, por favor elimínea. A distribución ou copia desta mensaxe non está autorizada. Nota: La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada. See more languages: http://www.sergas.es/aviso_confidencialidad.htm

13 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-users] using DateTime Picker from AppWithinMinutes Application

by Ludovic Dubost

Hi, It would be great to move the DatePicker as a simple setting in the class, though the DatePicker code itself should be modifiable to allow custom behaviors. It should be moved out of AppWithinMinutes into the XWiki core. Ludovic 2012/2/12 Eugen Colesnicov <ecolesnicov(a)gmail.com> > Sorry, I found answer. > Need to write {{include document="AppWithinMinutes.Date"/}} in a "custom > display" field of a class property. > > -- > View this message in context: > http://xwiki.475771.n2.nabble.com/using-DateTime-Picker-from-AppWithinMinut… > Sent from the XWiki- Users mailing list archive at Nabble.com. > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 7 months

1
0
0 0

[xwiki-devs] [Proposal] New Dates for XE 3.5

by Vincent Massol

Hi, As usual (*sigh*, we need to fix that!) we've lagged in the release of XE 3.5M1 and we need to define what are the new dates. Since we want 3.5 to be a short release I propose to do the following: * Skip 3.5M1 and instead go straight to 3.5RC1 * Release 3.5RC1 on Tuesday 14th (Marius who's the RM isn't available on the 13th). This means we need to start stabilizing **NOW** and fix all failing tests in order to be ready Tuesday morning. * Call 3.5RC1 the Love Release ;) since it's on Valentine's day… * Keep the 3.5 final date for the 20th of February WDYT? Thanks -Vincent

13 years, 7 months

5
7
0 0

[xwiki-devs] Pull request on meeting manager

by Ludovic Dubost

Hi, I've fixed meeting manager to work with XWiki 3.3 (at least) and CSRF in particular. I've commited the changed to a repo on my github account and issues a pull request, as apparently I could not commit myself. Who would be in charge of pull request on the meeting manager repo in xwiki-contrib. Here is my pull request: https://github.com/xwiki-contrib/application-meetingmanager/pull/1 Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

13 years, 7 months

2
2
0 0

[xwiki-devs] Local object references are not that local

by Thomas Mortagne

Hi devs, Denis just reported an issue he have while he is working on generating ids for the database: local reference to an object looks like "space.name^wiki:xspace.class[0]" which is not very local when the absolute reference is "wiki:space.name^wiki:xspace.class[0]" (will let him give more details on what issue it causes). I'm not sure what's the best for this. Here are some ideas: 1/ Relative references for class: change BaseObjectReference to generate a name based on a class reference relative to the document reference. So an absolute reference of an object would give "wiki:space.name^xspace.class[0]" which in turn is not fully absolute even of you can resolve the class reference based on the document. 2/ Local reference for class: pretty much the same thing as 1/ but never contain the wiki. Thing is the current storage does not support class coming from another wiki so would kind of make it "official" in the references generated by BaseObject. 3/ Custom serializer in oldcore: overwrite reference serializers in oldcore and parse the object name to also make the class reference follow the serializer rules (local, compact, etc.). 4/ Object guid as name: use object guid as name but right now guid can't be trusted (sometimes not set, sometimes duplicated, etc.) so it would require to fix some bugs first. 5/ Do nothing: and see this as a limitation of the object reference in the current storage. That means that anyone that really need a local reference for a BaseObject should generate the reference the way he want instead of asking it to BaseeObject before giving it to the serializer. Note that all of these solution generate already currently valid object references, it's mostly about choosing the best default reference. WDYT ? 1/ and 2/ mean that code counting on reference always having absolute reference will be broken, like some event listener on object and object properties modifications probably (would need to check). 3/ is a bit crappy from architecture point of view but at least the base object reference stay fully absolute 4/ is a bit dangerous right now and require to fix several bugs related to guids at least. Also it gives an object reference not very nice from human reading point of view. 5/ does not fix much even if it's possible to manage with a hack helper to get local reference but it's a hack 1/, 3/ and 5/ are nothing else that hacks from my point of view so I'm -0.5 for them 4/ is not a hack but I don't feel very comfortable with object uid that has never really been used (and so have several blocker bug still not fixed) so lets say -0 too 2/ is OK if we say that with BaseObject we will never support classes coming from another wiki. The next storage will have different kind of names for objects anyway not based on classes from what we discussed. It's a +0.5 for me (no solution give me 100% satisfaction but this one is the best until other arguments are exposed) -- Thomas Mortagne

13 years, 7 months

2
3
0 0

[xwiki-devs] [VOTE] New xwiki-commons-environment module

by Vincent Massol

Hi devs, Thomas and I have been brainstorming about the need to introduce a generic notion of Environment in XWiki Commons. The idea is that there are some modules that are currently in Platform that should/could be moved to Commons. To name just two: * Cache * Extension However these modules need a notion of Environment. They don't need the full notion of Container that we have in Platform though (they don't need the notion of request/response/session for example). So here's a proposal. * Introduce the following modules: xwiki-commons-environment |_ xwiki-commons-environment-api |_ xwiki-commons-environment-standard |_ xwiki-commons-environment-servlet * With the following Java content: - in xwiki-commons-environment-api: Environment (Interface) |_ getTemporaryDirectory() --> File |_ getPermanentDirectory() --> File |_ getResource() --> URL |_ getResourceAsStream() --> InputStream - in xwiki-commons-environment-standard @Named("default") StandardEnvironment |_ setResourceDirectory(File) |_ setTemporaryDirectory(File) |_ setPermanentDirectory(File) - in xwiki-commons-environment-servlet @Named("default") ServletEnvironment |_ setTemporaryDirectory(File) |_ setPermanentDirectory(File) Usage from other components: @Inject private Environment environment; * Usage in a standard environment (standard as in Java SE): ECM ecm = new ECM(); ecm.initialize(getClass().getClassLoader()); StandardEnvironment env = (StandardEnvironment) ecm.lookup(Environment.class); env.setPermanentDirectory(new File(…)); … However to make it simpler to initialize XWiki in a standard environment we will provide a System helper class in xwiki-commons-environment-standard: ECM ecm = System.initialize() <-- uses System classloader and sets tmp dir to java.io.tmp.dir, no permanent dir set, no resource dir ECM ecm = System.initialize(File permanentDirectory) <-- uses System classloader and sets tmp dir to java.io.tmp.dir, resource dir points to permanent dir ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory) <-- uses System classloader and sets tmp dir to java.io.tmp.dir ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory, File temporaryDirectory) <-- uses System classloader ECM ecm = System.initialize(File temporaryDirectory, File resourceDirectory, File temporaryDirectory, ClassLoader classLoader) ECM ecm = System.initialize(ClassLoader classLoader) <-- Sets tmp dir to java.io.tmp.dir, no permanent dir set, no resource dir Note: in 99% of use cases the user just has to write the following to initialize XWiki: ECM ecm = System.initialize(); * Technical impl details: - getTemporaryDirectory default to java.io.tmpdir - getResource default to getPermanentDir * Relationship with Container: - We initialize the Environment component in the Container init classes (DefaultServletContainerInitializer for Servlets) - We deprecate ApplicationContext. Code that's using ApplicationContext is now asked to use the Environment component instead Here's my +1 Thanks -Vincent

13 years, 7 months

4
5
0 0

[xwiki-devs] Adding CSS code into Xwiki skin

by Kaya Saman

Hi guys, I know I've asked this before so please bare with me and save the lynching for later ;-) I have added this CSS to the Xwiki file system and would like to add it to the Xwiki Skin Document instead....: body#body, #allviewpanels .accordionTabContentBox{background-image: url( ../../images/colors/gray/H4x4-GRAY.png); } body#body #xwikimaincontainer, body.hideright #xwikimaincontainer, body#body.hideright #xwikimaincontainerinner, body.importbody #xwikimaincontainerinner, body.exportbody #xwikimaincontainerinner, body.adminbody #xwikimaincontainerinner, body.hidelefthideright #xwikimaincontainerinner, body#body.hidelefthideright #xwikimaincontainerinner { background-image :url( ../../images/colors/bg/gpl-red.png) ; } #xwikimaincontainerinner, body#body.editbody #xwikimaincontainerinner, body#body.eportbody #xwikimaincontainer, body#body.importbody #xwikimaincontainer, body#body.adminbody #xwikimaincontainer, body#body.hidelefthideright #xwikimaincontainer, body#body.hideleft #xwikimaincontainer, body#body.editbody #xwikimaincontainer { background-image :url( ../../images/colors/bg/gpl_right-red.png) ;} body#body.editbody #globallinks, #globallinks, #rightPanels, #editPanels.panels{ background-image: url( ../../images/colors/bg/gpl-red.png);} #company { background-image: url( ../../images/colors/bg/gpl-red.png); } First of all where do I add it, into which section?? I created a new skin doc called WWW_Skin (I was told to not use Default Skin) - then select customize and insert where?? I tried adding to Style section and UI broke.... After I find the section what's the syntax to use???? Or would it be simpler to change the 'default stylesheet' under Admin -> Presentation and create my own style.css doc???? (which I kind of did anyway but it calls another css doc) Best regards, Kaya

13 years, 7 months

2
2
0 0

[xwiki-devs] [VOTE] Upgrades for the 4.x cycle

by Sergiu Dumitriu

Hi devs, I'd like to have an early decision on what (bigger) dependencies should be upgraded in the next release cycle. A) HTML 5. Already proposed by Jerome. This is something that has a continuous aspect, since "switching to HTML5" can be something as simple as writing a smaller DOCTYPE, or can go to rewriting the entire templates and rendering engine. We'll start small and improve things as we go. B) Hibernate 4. Will require some code changes since we're using a few deprecated APIs that have been removed in 4.0. C) Struts 2. We could move away from Struts completely at some point, but until we have the time to implement our own action mechanism, a good step forward is upgrading to a newer version of Struts. D) Velocity Tools 2. I'm not quite happy with how version 2.0 is packaged, since it brings in a dependency on Struts 2, but 2.1 isn't planned yet. Alternatively, we could package our own subset of velotools, since we're only using the generic tools, not VelocityView or VelocityStruts. E) Servlets 3.0. Since we're using Java 1.6, we could also require a servlet-3.0 capable container. This will give us more flexibility in defining servlets and filters, since the 2.4 versions we're using now requires a central web.xml file. The problem is that only the most recent versions of the popular servlet containers are compatible: Jetty 8, Tomcat 7, Glassfish 3, WebSphere 8, WebLogic 12. Oracle Application Server doesn't provide a version compatible with servlets 3.0, but this server is discontinued anyway. This means that users on older Linux server versions will have to install Tomcat 7 manually. F) Jetty 8. This is required for Servlets 3.0, but it would be a good upgrade on its own. G) HSQLDB 2. Better for performance. H) Lucene 3.5, Tika 1.0. Upgrading Lucene shouldn't be a problem, but an early attempt at using Tika 1.0 didn't work, it would require some time to debug it. I). Sass, Less or something like that. Personally I'm against this, since we're already providing support for most of their benefits by including Velocity code in CSS files. Does anybody else consider that we should include a CSS framework? J) Joda Time 2 and Quartz 2, and maybe freshen up the plugins that use them. WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

13 years, 7 months

6
6
0 0

[xwiki-devs] [VOTE] Naming rules for translation resource properties + deprecated properties

by Vincent Massol

Hi devs, I see that in ApplicationResources.properties we now have some wrongly named properties. For example for the scheduler I find properties of the type xe.scheduler.* but the scheduler is now in the platform. There are also resources named core.* Thus I'd like to propose a simple rule: <short top level projet name>.<short module name>.<propertyName> where: <short top level projet name> = top level projet name without the "xwiki-" prefix, for example: commons, rendering, platform, enterprise, manager, etc <short module name> = the name of the maven module without the <short top level project name> prefix, for example: oldcore, scheduler, activitystream, etc <propertyName> = the name of the property using camel case, ex: updateJobClassCommitComment For example the property core.importer.package.version would be renamed in platform.web.packageVersion The only issue is when we rename modules we need to rename the properties for that module but I don't see any way out of this if we want to have expressive property names. But at least it's an easy and mechanic change I also propose to introduce a different resource property file that will hold deprecated properties and that we can put in the xwiki-platform-legacy module. We could call it DeprecatedApplicationResources*.properties Of course in the future each module should be able to contribute both resource properties (but they would use the same naming scheme!). Even though this is not the topic of this mail this is how I'd implement this in the future: * Implement a TranslationPropertiesConfigurationSource that is initialized by reading all property files found in the classloader under META-INF/translations.properties and META-INF/translations-deprecated.properties. This component would listen to observation events so that when a new jar is installed by the extension manager it can check if it provides some translations and add them. * Have a Translation Manager component which is the main API to be used by other modules wishing to get translations. This manager would use the TranslationPropertiesConfigurationSource component. Here's my +1 Thanks -Vincent

13 years, 7 months

6
8
0 0

[xwiki-devs] JIRA Calendar - Needs to be up to date

by Vincent Massol

Hi devs, Just to let you know that I've fixed the calendar in the system dashboard: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000 I've also set all planned release dates for Commons, Rendering, Platform, XE and XEM. We need to remember to set them whenever we decide roadmap dates and whenever we change those dates. This calendar is linked from our roadmap pages on xwiki.org so we need to keep it up to date. Thanks -Vincent

13 years, 7 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] XWiki updates, 2, 077 documents have been modified since 2012/01/30

by Thomas Mortagne

On Tue, Jan 31, 2012 at 12:01 AM, <watchlist(a)xwiki.org> wrote: > Error number 4001 in 4: Error while parsing velocity page > xwiki:XWiki.WatchListMessage Wrapped Exception: Failed to evaluate content > with id [xwiki:XWiki.WatchListMessage] > > Error number 4001 in 4: Error while parsing velocity page > xwiki:XWiki.WatchListMessage > Wrapped Exception: Failed to evaluate content with id > [xwiki:XWiki.WatchListMessage] > com.xpn.xwiki.XWikiException: Error number 4001 in 4: Error while parsing > velocity page xwiki:XWiki.WatchListMessage > Wrapped Exception: Failed to evaluate content with id > [xwiki:XWiki.WatchListMessage] > at > com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:122) > at > com.xpn.xwiki.plugin.mailsender.MailSenderPlugin.sendMailFromTemplate(MailSenderPlugin.java:813) > at > com.xpn.xwiki.plugin.watchlist.WatchListNotifier.sendEmailNotification(WatchListNotifier.java:133) > at > com.xpn.xwiki.plugin.watchlist.WatchListJob.executeJob(WatchListJob.java:270) > at com.xpn.xwiki.plugin.scheduler.AbstractJob.execute(AbstractJob.java:71) > at org.quartz.core.JobRunShell.run(JobRunShell.java:202) > at > org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525) > Caused by: org.xwiki.velocity.XWikiVelocityException: Failed to evaluate > content with id [xwiki:XWiki.WatchListMessage] > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:247) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:184) > at > com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:117) > ... 6 more > Caused by: org.apache.velocity.exception.MethodInvocationException: > Invocation of method 'getHTMLDiff' in class > com.xpn.xwiki.plugin.watchlist.WatchListEvent threw exception > java.lang.NullPointerException at xwiki:XWiki.WatchListMessage[line 148, > column 33] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) > at org.apache.velocity.context.ProxyVMContext.get(ProxyVMContext.java:219) > at > org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:991) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:240) > at > org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) > at > org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) > at > org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) > at > org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) > at > org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) > at > org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at > org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420) > at > org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228) > ... 8 more > Caused by: java.lang.NullPointerException > at com.xpn.xwiki.objects.BaseProperty.equals(BaseProperty.java:108) > at com.xpn.xwiki.objects.NumberProperty.equals(NumberProperty.java:57) > at com.xpn.xwiki.objects.BaseCollection.equals(BaseCollection.java:624) > at com.xpn.xwiki.objects.classes.BaseClass.getDiff(BaseClass.java:1211) > at com.xpn.xwiki.doc.XWikiDocument.getClassDiff(XWikiDocument.java:5600) > at > com.xpn.xwiki.plugin.watchlist.WatchListEvent.getHTMLDiff(WatchListEvent.java:534) > at sun.reflect.GeneratedMethodAccessor706.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) > ... 27 more > > > Wrapped Exception: > > org.apache.velocity.exception.MethodInvocationException: Invocation of > method 'getHTMLDiff' in class com.xpn.xwiki.plugin.watchlist.WatchListEvent > threw exception java.lang.NullPointerException at > xwiki:XWiki.WatchListMessage[line 148, column 33] > at > org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:243) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:187) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280) > at org.apache.velocity.context.ProxyVMContext.get(ProxyVMContext.java:219) > at > org.apache.velocity.runtime.parser.node.ASTReference.getVariableValue(ASTReference.java:991) > at > org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:240) > at > org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567) > at > org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71) > at > org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at > org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:216) > at > org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:311) > at > org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230) > at > org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at > org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87) > at > org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) > at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420) > at > org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) > at > org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:228) > at > org.xwiki.velocity.internal.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:184) > at > com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:117) > at > com.xpn.xwiki.plugin.mailsender.MailSenderPlugin.sendMailFromTemplate(MailSenderPlugin.java:813) > at > com.xpn.xwiki.plugin.watchlist.WatchListNotifier.sendEmailNotification(WatchListNotifier.java:133) > at > com.xpn.xwiki.plugin.watchlist.WatchListJob.executeJob(WatchListJob.java:270) > at com.xpn.xwiki.plugin.scheduler.AbstractJob.execute(AbstractJob.java:71) > at org.quartz.core.JobRunShell.run(JobRunShell.java:202) > at > org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:525) > Caused by: java.lang.NullPointerException > at com.xpn.xwiki.objects.BaseProperty.equals(BaseProperty.java:108) > at com.xpn.xwiki.objects.NumberProperty.equals(NumberProperty.java:57) > at com.xpn.xwiki.objects.BaseCollection.equals(BaseCollection.java:624) > at com.xpn.xwiki.objects.classes.BaseClass.getDiff(BaseClass.java:1211) > at com.xpn.xwiki.doc.XWikiDocument.getClassDiff(XWikiDocument.java:5600) > at > com.xpn.xwiki.plugin.watchlist.WatchListEvent.getHTMLDiff(WatchListEvent.java:534) > at sun.reflect.GeneratedMethodAccessor706.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395) > at > org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384) > at > org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173) > ... 27 more > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > A pity we don't have the document and the compared version or at least the field name in the log. According to the error, some property class has a new number field compared to 3.1.1. Does this sounds expected to anyone ? -- Thomas Mortagne

13 years, 7 months

1
2
0 0

[xwiki-devs] a page-sources project?

by Paul Libbrecht

Hello fellow XWikiers, I am regularly working with my favorite IDE, IntelliJ IDEA, and it is doing a very good work for me to edit velocity and groovy. I am using this also for the source of wiki pages which I upload using a tiny upload script (that posts like a form using curl and simple preemptive authentication, [1]). The interest of storing page-sources as files is that you get all the IDE services (it could work with most IDEs) such as auto-completion, code-usage-tracking, or html and javascript validation. The other interest is that my source files enter versioning. I can commit these so that I and other developers know it's part of the build for the future, independently of my server upload and developer readable in versioning system. Thus far I've been using wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...). There's a single issue I stumble across: for IntelliJ to do me classpath resolution (e.g. recognize an import for the Context class), I need to change the maven project type from xar to jar. And this is not so good. My next step would thus be to create a new sub-project, xwikipages, containing these pages... but maybe everything is wrong here. My questions: • how much of that is good or best practice? • what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git xwiki-application?) • is anyone else interested into sharing such a practice and enhance it commonly? thanks in advance Paul [1] upload-to-wiki can be found in https://github.com/xwiki-contrib/xwiki-clams-core/tree/master/tools/src/mai…

13 years, 7 months

4
6
0 0

[xwiki-devs] [Proposal] Use liquibase to manage the database schema

by Denis Gervalle

While trying to reduce the likelihood of duplicate ids for documents, and extending my patch to provide a proper solution for objects, I fall on a really unexpected issue: the type of the object identifiers are Integer where those of documents are Long. This is completely abnormal since we have several objects per documents, and therefore we need more distinct ids for objects than documents. I have therefore upgraded the ids of objects to use Long, and provide an implementation that use the lowest 64bits of an MD5 key for object in the same way I do for documents. This implementation introduce two new serializer: UidStringEntityReferenceSerializer and LocalUidStringEntityReferenceSerializer. I have also bridged the statistics that derived from objects. The new implementation works perfectly on a new database but... ... I am unable to provide a proper migration procedure, since hibernate cannot manage changing the types of existing columns. It does not complains during schema update, it simply do nothing about them. And later the data migration breaks since my hashes cannot fit in the database properly. After thorough googling, I understand that hibernate schema updates were not made for production use and are really limited opposed to the general idea we had of it. Since I am currently stucked, I propose to move ahead and use a new tool to properly manage our database schema upgrade: http://www.liquibase.org/ Liquibase is Apache licensed and provide a database agnostic version system for migrating databases. It does not works like a diff tool, but more like a patch tool, where you provide several XML description of your wanted changes and it manage to apply or rollback there changes in an ordered manner to upgrade the database to the latest schema. There is several way to apply these changes and I would like to see if it could be integrated in our current migration procedure, or at least as an independent listener. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

13 years, 7 months

3
4
0 0

[xwiki-devs] [Vote] Dates for 3.5 release

by Marius Dumitru Florea

Hi devs, In a previous mail I proposed the following dates for 3.5: 3.5RC1: 6 February (2 weeks) 3.5Final: 13 February (1 week) As you can see I haven't included a milestone because the initial plan was to do only bug fixes as 3.5 is the last release of the 3.x cycle. It seems though that we're going to introduce new stuff and improvements (for Extension Manager and App Within Minutes at least) and thus a milestone is now needed. Thus I propose these new dates: 3.5M1: 6 February (2 weeks) 3.5RC1: 13 February (1 week) 3.5Final: 20 February (1 week) WDYT? Thanks, Marius

13 years, 7 months

6
5
0 0

[xwiki-devs] XAR Import Ant Task

by Richard Hierlmeier

Hi Developers, I implement an ant task that allows the import of xar files into a xwiki database. This Tasks uses a class that is derived from AbstractPackager. Whenever an object of this class calls AbstractPackager.createXWikiContext I get an exception with the following root cause: Caused by: java.lang.NullPointerException at org.xwiki.context.internal.DefaultExecutionContextManager.initialize(DefaultExecutionContextManager.java:138) at com.xpn.xwiki.tool.backup.AbstractPackager.createXWikiContext(AbstractPackager.java:75) at ... It seems that this AbstractPackager.createXWikiContext method works only on some circumstances. I assume that the injection mechanism is not working in my case. In a seconds test I implemented a main method in the AntTask, and provided the parameter via command line. And it worked but only under the condition that the required classpath is defined in the manifest of the jar and the program is started via java -jar xarImportAntTask.jar When I setup the classpath externally and start it with java -cp ... de.hierlmeier.xwiki.ant.XarImportTask I get the same NullPointerException as within ant. Can someone give me a hint to solve the problem? If anyone is interrested I can contribute the ant task to the open source community (once it is working). Here is a sample ant configuration: <taskdef name="importXar" classname="de.hierlmeier.xwiki.ant.XarImportTask"> <classpath> <pathelement location="${instdir}/xwiki/WEB-INF"/> <pathelement location="${instdir}/xwiki/WEB-INF/classes"/> <fileset dir="${instdir}/xwiki/WEB-INF/lib"> <include name="*.jar"/> </fileset> </classpath> </taskdef> <importXar hibernateConfig="${instdir}/xwiki/WEB-INF/hibernate.cfg.xml" xwikidb="xwiki"> <xarFiles dir="${basedir}/xars"> <include name="*.xar"/> </xarFiles> </importXar> Thank you in advance Richard

13 years, 7 months

1
0
0 0

[xwiki-devs] [VOTE] Create Committers list for internal committers stuff + use it for collecting poll results

by Vincent Massol

Hi devs, We had already discussed the creation of a committers list earlier, see http://markmail.org/thread/bnimte63t3tojslz I'd like to revive this topic in view of a new use case: poll results. We're going to launch our feature survey and we need a way to collect the results and receive email results. I'm thus proposing to use this committers list to collect the results (a mail is sent when someone fills in the poll). Note that we cannot publish results openly since: * there's an optional email address we can't put that in public * people may not want to share their results with everyone publicly Here's my +1 to the creation of this private committers list and for using it to send poll results. Thanks -Vincent

13 years, 7 months

8
9
0 0

[xwiki-devs] [VOTE] Move JIRA macro to platform and make it a java macro

by Vincent Massol

Hi devs, I'd like to propose that we rewrite the JIRAwiki macro currently located at https://github.com/xwiki-contrib/macro-jira as a java macro in platform. Rationale: * Easier to debug and provide unit tests for * It's an important macro for our users * It's useful to us devs too since we use it on xwiki.org Here's my +1 Thanks -Vincent

13 years, 7 months

7
6
0 0

[xwiki-devs] Call for test Extension Manager

by Thomas Mortagne

Hi xwikiers, I just add clustering support which was the last big peace of framework that was blocking a first fully functional version of Extension Manager. I will now dedicate my time to write tests and fix bugs and small improvements I find and try to fix some UI bugs too if Sergiu does not have time. I also have some improvement work in XWiki Repository and finally make extension.xwiki.org fully based on standard XWiki Repository and not have custom version anymore. During the 3.5 and 4.0 timeframe it would be nice to get as much tests and reports as possible on what is not working or still blocker in term or usability so that we get a nice and strong first version we can advertise in 4.0. There is obviously lots of possible improvements some of which you can find on http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager (and I need to add more things in there) but I would like to limit to a fully working minimum for 4.0 and then do a priority survey on the many new features and improvements ideas. Here are the grey areas I know about and on which I'm going to concentrate on writing tests: * automatic xar merging is a quick implementation not excessively tested. Also the string properties content merging is not able to merge modification done on the same line which is not nice when things like the title is customized in the wiki and also changed in the new version of the xar. Right now in doubt the merge always take the new version when there is a conflict so that nothing is lost since it's easy to get back the previous version from the history. Also I'm not going to have time to work on a real manual conflict resolution UI for this timeframe, not alone at least. * clustering is a bit young ;) Also it expect all members to have the exact same constraints, if for any reason an extension is installed to a member and fail on another it could create quite a mess if that's an important extension. * it's not very hard to add versions and dependencies in XWiki Repository but it require using object editor which is not very nice for all profiles of users (now it's generally done by the developer of the extension so not a basic user either). Will try to work on that if I have some time left. Thanks, -- Thomas Mortagne

13 years, 7 months

1
1
0 0

[xwiki-devs] [Proposal] New Feature survey for the 4.x cycle and beyond

by Vincent Massol

Hi devs, In 2009 we launched a survey on xwiki.org: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2009 The results were published here: - http://www.xwiki.org/xwiki/bin/view/Blog/Features+Survey+Results - http://www.xwiki.org/xwiki/bin/view/Blog/FeatureStatus20120119 The idea is to do that same with a new survey. Benjamin Lanciaux (from XWiki SAS) has prepared one here: http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2012 Please let me know if you're ok and I'll send the survey on the user list. Thanks -Vincent

13 years, 7 months

6
12
0 0

[xwiki-devs] XWiki Enterprise and XWiki Enterprise Manager 3.4 Released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.4. XWiki Enterprise 3.4 is a stabilization release as we're approaching the end of the 3.x cycle so its main goal was to improve the Extension Manager and App Within Minutes features. However, this release also comes with a new look and a new default wiki page syntax. The highlights of this release are: * New color themes * XWiki 2.1 is the default page syntax * Improved Extension Manager UI * Delete space menu * Simple space templates * Special characters in attachment file names * Minimized action menu * Display macro See the full release notes at http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… for more details. Thanks -The XWiki dev team

13 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs