Hello everybody,
I have created a JIRA macro using groovy. This macro allows to query JIRA
(using issue keys or using JQL) in order to obtain desired information.
The information can be displayed in several ways (tables, list, enum)
depending on what the user wants.
Also, this macro supports other several options in order to suit users'
needs.
I would like to contribute it and I also request if the community can host
it on github. Everyone interested in it could contribute to it
My github ID is sorinello. https://github.com/sorinello
Thanks, and I hope you will use this macro on a daily basis :)
Regards,
Sorin B.
The XWiki development team is proud to announce the availability of
XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and
XWiki Enterprise Manager 3.3 Milestone 1. Since we're getting closer to
the end of the 3.x cycle, there are fewer new features in this release,
most of the changes being internal. The highlights of this release are:
* a preview version of the new class editor to be used in the
Application Within Minutes designer
* new Debian packages for XWiki
* a few extension manager improvements
* LDAP improvements
* improvements on uploading and downloading attachments, especially when
filesystem storage is enabled
And on the developers' front:
* script services for Application Manager and Wiki Manager
* cache improvements
* changes in the way XAR modules are packaged
* and the usual dependency upgrades and translation improvements
See the full release notes at
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise33M1
for more details.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
A little week-end fun which can turn out quite useful. I've coded a Google
Apps Integration module.
It allows to:
- search for a document in your Google Docs instance and upload it to an
XWiki page.
- to click on an "edit link" (like webdav) to open an attachment in Google
Docs, then edit it (in another tab), and then in one click retrieve it to
resave it in XWiki.
- the latest feature supports overwriting a document with the same name in
your Google Docs instance or to create a new separate file.
The extension is here and the code in GitHub:
http://extensions.xwiki.org/xwiki/bin/view/Extension/GoogleAppsIntegration
It's only using a XAR + Groovy and does not need any templates modification
(the attachment zone is enhanced by a JSX).
Some stuff that could be added:
- automatically give more rights for others to edit
- send a Wiki content or a Wiki table to Google Docs and resave in the Wiki
page (I leave that to XWiki rendering specialists :))
- additional UI feature to possibly use a Lightbox to launch the editing
and the edit screen
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
I've created a new FAQ application.
It's currently available from http://www.xwiki.org/xwiki/bin/view/FAQ/WebHomeNew
(it's linked from the old one: http://www.xwiki.org/xwiki/bin/view/FAQ/WebHome)
The reason I rewrote it is because I think FAQs are important and that we're not using it enough
Here's how I think it could work out:
* If a user has a question he/she should verify if it's already in the FAQ. If not then he/she should post a message for the XWiki Mailing List/Forum.
* The strategy is then for people who know the answer to create a new FAQ entry about the question and reply in the mail with the link to the new FAQ Entry
In this manner we will quickly enrich this FAQ database.
Of course the FAQ answers should be as short as possible and point to existing docs (if those docs don't exist they should be updated/created).
Basically I see FAQ as entry points to our documentation, from the point of view of someone asking questions of the type "how do I….".
Thus there can be several FAQ entries all having the same link to the documentation.
WDYT?
Thanks
-Vincent
PS: As you can see I have only 4 entries right now since we need to migrate exisitng FAQ entries:
- use a good page name
- rewrite them in XWiki Syntax 2.0
- verify their accuracy
- update docs where needed
Maybe we should have a FAQ day to work on that?
Hello,
There are a lot of browsers out there and supporting them all in all
versions is just too hard to be done in a quality manner with the number of
committers we have. In addition we should try to explicitly list the level
of support we have for each browser on xwiki.org so that users know what to
expect, on a release by release basis.
Thus I believe that we need a strategy and a general agreement about what
browsers we want to support. I propose that by "supporting" we mean:
- issues created for these browsers in jira are not closed as won't fix and
we make a best effort to fix them
- we include these browsers in our tests (be them automated or manual)
- when we create new features or modify existing features we make a best
effort to verify that they work on the supported list of browsers
So here's a proposal:
* Drop IE6 support - Dropping IE6 will provide a lot of benefits: 1) allow
us to use newer technologies which are more useful, 2) remove lots of hacks
we've accumulated over the years and 3) have more time to work on more
relevant browser versions. A lot of products have now dropped support for
IE6 and it's time we do it too.
* Drop IE7 support - Currently, IE7's market share is similar to the one of
IE6. They are both considered obsolete browsers for the same reasons as IE6
* Support IE8 - currently IE8 has the largest market share of all IEs and it
is widely used in enterprise environments.
* Support IE9 starting with 3.3 release - IE9 is slowly getting ground in
front of IE8
* Support Mozilla Firefox 3.6 - even with the new release stragtegy of
Mozilla, Firefox 3.6 still has aprox. 50% of all Mozilla browsers. This
browser is still supported officially by Mozilla
* Support Mozilla Firefox 4 and newer - The proposal is to support only the
latest stable Firefox release since FF4+ have automatic upgrades.
* Support Google Chrome 13 an newer - support the latest stable version of
Chrome released as with FF4+
* Support Safari 5 in XWiki 3.3 and newer.
* Don't officially support Opera - This means that we don't test against it
all the time, we don't ensure that new feature work on it but if someone
raises an issue in jira and it's easy to fix (or if someone provides a
patch) then we fix it.
* For all other non mentioned browsers - We don't officially support them
(same strategy as for Opera above)
I also propose that in the Release notes for each version of XWiki we
mention the list of browsers we have tested against and that we "support".
Best regards,
Sorin B.
Done
On Wed, Oct 26, 2011 at 7:09 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> Hi devs,
>
> Right now it's not very easy for a macro to properly deal with content
> parsing especially the way to find which syntax to use to parse the
> content.
>
> There is a very useful tool that we are using internally but its not
> public so contribution macros can't use that.
>
> I propose to move
> org.xwiki.rendering.internal.macro.MacroContentParser to
> org.xwiki.rendering.macro.MacroContentParser.
>
> WDYT ?
>
> Here is my +1
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
Hi devs,
Right now it's not very easy for a macro to properly deal with content
parsing especially the way to find which syntax to use to parse the
content.
There is a very useful tool that we are using internally but its not
public so contribution macros can't use that.
I propose to move
org.xwiki.rendering.internal.macro.MacroContentParser to
org.xwiki.rendering.macro.MacroContentParser.
WDYT ?
Here is my +1
--
Thomas Mortagne
Recently I setup my project on cia.vc and enabled a bot to print changes in my irc channel and I'd like to do that for XWiki as well.
Pros:
* Almost no effort - it's about 10 minutes of work, if we don't like it there's very little lost.
* XWiki exposure and statistics tracking on cia.vc
* Immediate notification of commits which is not mixed in with Hudson noise, job offers and important notices from Nigerian royalty.
I don't read all of my mail as it comes it, I have it automatically sorted and archived so I can search it later as a historical record,
this proposal benefits people who use mail the way I do.
Cons:
* Information about commits is duplicated.
any others?
WDYT?
Caleb