Hi devs,
We've had a meeting with Marius, Thomas and myself and we brainstormed about what to improve in our builds and we've come up with the following actions:
1- create twitter account for xwiki.org and tweet about releases (basically tweet links to blog posts). Category: Release Process improvement. Who: Vincent Massol
2- Refactor distribution for installers to share more. Who: Thomas Mortagne
3- Check latest version of izpack. Who: Marius
4- Configure nexus to cache other repos → speed improvement. Who: Vincent Massol
5- Add definition xwiki remote repo to top level repos in github. Who: Vincent Massol
6- Define a location for passwords. Who: Thomas Mortagne
7- Publish with commons and rendering on central repo. Who: ?
I've started to work on items 4 and 5 and will do 1 soon.
Also I've analyzed 7 and there's only 1 external reps not available in the Maven Central Repo:
<groupId>org.reflections</groupId>
<artifactId>reflections</artifactId>
It should be pretty easy to submit it using https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+…
To publish our artifacts to the central repo I propose to use Sonatype OSS service, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+…
Thanks
-Vincent
Hello,
is there any example which shows usage of DBStringList property together
with support for selecting multiple values of this property (by for
example using checkboxes) and also showing how such values are later
obtained from the property?
I'm asking since I'm not sure if property is able to kind of change into
property list (probably) and also I'm fighting with this and I'm still
not able to obtain more than one value from returned property object.
Thanks!
Karel
Hi devs,
I'd like that we remove code that we've moved to github from svn.xwiki.org as it's misleading for people arriving there.
Secifically:
- commons
- enterprise
- manager
- platform
- rendering
- watch
- xeclipse
- xoffice
Here's my +1
Thanks
-Vincent
Hello again,
I would like to introduce a new module in platform : xwiki-platform-thumbnails.
The idea of the module is to provide means of handling thumbnails in
XWiki. Right now the main purpose is to expose APIs to retrieve
thumbnails URLs for images stored as attachments. This module first
use will be to generate thumbnails of user avatars. In this scenario,
it will also introduce a performance improvement compared to today's
way of computing avatar URLS, since the module caches both the
property values (the fact that user X has set an avatar Z.png) and the
thumbnail URL for this avatar.
I've already pushed it in a feature branch/. You can check in
particular https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba…
and all commits in the branch at
https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails
Let me know what you think.
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
Hi devs,
I think we all agree that the result of
{{include document="Space.Page" context="new" /}}
must be similar with what we see when we view Space.Page. Now, suppose
Space.Page has an object of type Space.Class and Space.Class has a
sheet named Space.Sheet. If the sheet is applied to Space.Page using
the include macro in the content field like this:
{{include document="Space.Sheet" /}}
then the result of the first include macro is as expected. If we don't
use the content field to apply the sheet (which is the case of the
sheet management module I'm working on) then the result of the first
include macro is not anymore as expected. The reason is that rendering
the content of Space.Page (could be empty) is different than rendering
the Space.Sheet in the context of Space.Page.
I could modify the include macro to use the sheet module when
context=new, but I think it's better to hide the sheet module from the
include macro, e.g. by modifying the getRenderedContent() method to
use the sheet module instead.
WDYT?
Thanks,
Marius
I have a macro (implemented in Java) with this interface:
public List<Block> execute(InferenceParameter parameters, String
content, MacroTransformationContext context) ;
I want to call this macro from within a velocity script. When I do, it
returns a List<Block>. How do I get the velocity script to render the
List<Block> properly?
--
Mark Wallace
Principal Engineer, Semantic Applications
Modus Operandi, Melbourne, FL, USA
Hi devs,
I'd like to stop sending jenkins emails for the 3.1 builds for the following reason:
* We don't have enough time to fix the tests on that branch as we did for the master branch
* Almost all (if not all) emails are false positives
* We're stabilizing the build and we're trying to reduce all false positive emails and this is not helping us go in the right direction
* This branch is supposed to go away in not too long
* We don't do many commits on that branch (and we shouldn't)
So the idea is that we don't receive emails anymore for that branch **but** it'll be up to the Release Manager when we release this branch to review the failing tests with the other devs when it's time to release it to ensure that we don't have real test failures.
WDYT?
Thanks
-Vincent
Hi devs,
I started to move (very) old notification system to legacy but I'm
stuck because there is one thing still not supported by new
observation system: event sent before executing an action.
So here it is: I propose to add it with the name ActionExecutingEvent
in the bridge.
At the same time I would also like to come with ActionExecutedEvent in
the bridge to replace the ActionExecuteEvent which is currently in
observation API (and that should never have been there).
WDYT ?
here is my +1
--
Thomas Mortagne
Hi devs,
I'm working on a sheet management module (see
https://github.com/xwiki/xwiki-platform/compare/feature-sheets ) and I
have an issue. My component returns the list of sheets "registered"
for a document or a class. The component methods take document
references as input. The consequence is that my component always
"queries" the saved document (taken from the database/cache). I have
modified the edit.vm template to check if there is a sheet available
for the current document. It works great with one exception: when you
create a document (e.g. when you create a blog post).
The problem is this: although the information required to detect the
sheet is present on the current/context document (e.g. it has an
object of type BlogPostClass) my component fails to access this
information because the document wasn't saved, it doesn't even exist.
The reason I used document references on my component interface is
obvious: I didn't want to depend on the core (at least not the
interface, because the implementation does right now). The solution to
keep the current component interface is to explicitly specify the
sheet on the edit URL (only) for the create form. For instance,
replace:
/edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate
with:
/edit/Blog/MyNewBlogPost?template=Blog.BlogPostTemplate&sheet=Blog.BlogPostSheet
but I think it's a bit too much to ask from the application developers.
Another solution, suggested by Thomas Mortagne, is to:
* change the component interface to use DocumentModelBridge (which is
implemented by XWikiDocument) instead of DocumentReference (=> keep
the interface independent of old core)
* change the script service to use api.Document instead of
DocumentReference, and to extract the XWikiDocument from it through
reflection, to avoid programming rights issues.
It's not a clean solution but it is better from the application
developers' point of view.
WDYT? Any alternatives?
Thanks,
Marius
Hi Devs,
The current hasAdminRights(XWikiContext) method checks if the current user
has admin rights on the current wiki or on the current space. However, the
javadoc currently available (and also general knowledge) did not include the
"or current space" part and the method ended up being used in places where
admin right for the current space was not enough to allow performing certain
actions (ex. wiki manager plugin, etc.)
While it is still useful to check for admin right on wiki or space, it is
more useful to have a method that checks admin right only for the wiki
(stronger admin). Using the current api, it's cumbersome to have to specify
"XWiki.XWikiPreferences" each time so I propose adding a new method to
handle this:
/**
* Checks that the current user in the context (the currently
authenticated user) has administration rights on the
* current wiki, regardless of any space admin rights that might also be
available.
*
* @param context the xwiki context of this request
* @return {@code true} if the current user in the context has the
{@code admin} right, {@code false} otherwise
*/
public boolean hasWikiAdminRights(XWikiContext context);
And, obviously, the fixed javadoc for hasAdminRights(XWikiContext).
You can check out the pull request at
https://github.com/xwiki/xwiki-platform/pull/22
Here's my +1
Thanks,
Eduard
P.S.: Existing code using the hasAdminRights(XWikiContext) method will have
to be adjusted accordingly.