I would like to take this time to welcome you to our hiring process
and give you a brief synopsis of the position's benefits and requirements.
If you are taking a career break, are on a maternity leave,
recently retired or simply looking for some part-time job, this position is for you.
Occupation: Flexible schedule 1 to 3 hours per day. We can guarantee a minimum 20 hrs/week occupation
Salary: Starting salary is 3000 EUR per month plus commission.
Region: European Union.
Please note that there are no startup fees or deposits to start working for us.
To request an application form, schedule your interview and receive more information about this position
please reply to Chauncey(a)it-jobsearch.com with your personal identification number for this position IDNO: 9101
hi devs,
The idea is that in Maven in general you should never embed anything
except for final distribution packages that are not supposed to be
used as dependencies of other maven projects (installers, standalone
packages, etc.). This will also allow us to properly setup
dependencies in xar so that dependency is installed when installing a
xar in Extension Manager without its pages being imported twice.
So I propose the following changes:
* in xar plugin:
** stop embedding dependencies as default behavior
** introduce an optional property for it.
* in XE/XEM have two different xars:
** a normal one with just XE pages and proper dependencies setup
** a "standalone" one which embed all XE dependencies xar (basically
the one we have now)
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi devs,
I need to fix, and I have a proposed commit at
https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e3…
Basically, it does the following:
a) Add XWikiDocument#getKey() which return a unique text key like
8:fullname2:fr
b) Add XWikiDocument#getKey(context) which return a unique text key like
5:xwiki8:fullname2:fr
c) Change XWikiDocument#getId() to use the lowest 64bits of an MD5 hash
of XWikiDocument#getKey()
d) Deprecate all XWikiCacheStore#getKey(...) and
use XWikiDocument#getKey(context) for the XWikiCacheStore map
e) Introduce a data migration to convert existing database, also fixing
links, rcs, attachements and deleted attachements use of docid.
I am +1 only after XWIKI-7006 is fixed (see my previous vote), since any
improper access to an outdated database would corrupt it.
Currently the patch is ready for 3.3, but if XWIKI-7006 goes in 3.2, I am
also +1 to have this in 3.2.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi everybody,
I would like to propose Jun Han as a new committer on
https://github.com/xwiki/xwiki-eclipse
Jun took part to the last GSoC, working on the RESTification of XEclipse.
The project aimed at developing a new backend for XEclipse so that it
could take advantage of the XWiki RESTful API.
Jun has been successfull in completing the project, delivered a good
quality result and he also contributed fixing several
bugs not directly related to the GSoC project.
His work has been presented in a previous mail
(http://markmail.org/thread/3udg2fycaaeg4sun) and has been merged in
the master branch and will be the core of the next release.
Jun was also very active during the GSoC and, though he's very busy
with his own activities, he's very responsive even now that the GSoC
is over (which is a very big +)
So here it is my +1 for having Jun as a committer on XEclipse.
Thanks,
Fabio
3 "+1", 1 "+0" and not other vote. Done.
On Mon, Oct 10, 2011 at 8:44 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> Hi devs,
>
> I just finished and committed an Infinispan
> (http://www.jboss.org/infinispan) based cache API implementation.
>
> I would like to propose to move to it by default instead of the JBossCache one.
>
> Pros:
> * Infinispan is basically the new name of JBossCache starting with version 4
> * as far as I can see the perf are a bit better especially in the
> creation of new cache which is important for the cache macro which
> potentially create lot's of caches
>
> WDYT ?
>
> here is my +1
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
Hi dev,
The new query manager component work pretty well and starts to be used
more and more so I think we should remove com.xpn.xwiki.plugin.query.
So here is the proposals:
(1) move it to legacy
(2) move it to retired is it's own maven project so that it's easy to
build and produce a jar if someone wants to use it
Note planning to do it in 3.2, that's for 3.3M1.
WDYT ?
+1 for (2): it's the last thing that trigger dependency on jackrabbit
so even if we get rid of jackrabbit in oldcore by moving it to
legacy-oldcore it would still be in XE
--
Thomas Mortagne
The XWiki development team is proud to announce the availability of
XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and
XWiki Enterprise Manager 3.2. Following the goals established for the
3.x cycle, XWiki Enterprise 3.2 pushes forward in the directions of the
Application Within Minutes and Extension Manager features. The
highlights of this release are:
* many extension manager improvements
* new implementation of the sheet system making it easier to bind sheets
to objects without an explicit inclusion of the sheet in the document
content
* user dashboards giving each user the possibility to configure their
own home page
* introduction of wiki workspaces, as a more collaborative way of
managing an XWiki virtual farm
* improvements of search results scoring
* storage improvements, bringing in numerous performance and
compatibility improvements
* conversion of the panels application to the XWiki 2.0+ syntax
* easier activation and configuration of Google Analytics
And on the developers' front:
* CSRF prevention enabled by default
* support for DocBook syntax
* xwiki-commons and xwiki-rendering are now published on the central
Maven2 repository
* some major code cleanup due to the retirement of some very old plugins
and the move of legacy/deprecated code into separate modules
See the full release notes at
http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32 for
more details.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
I just finished and committed an Infinispan
(http://www.jboss.org/infinispan) based cache API implementation.
I would like to propose to move to it by default instead of the JBossCache one.
Pros:
* Infinispan is basically the new name of JBossCache starting with version 4
* as far as I can see the perf are a bit better especially in the
creation of new cache which is important for the cache macro which
potentially create lot's of caches
WDYT ?
here is my +1
--
Thomas Mortagne
Hi Devs,
We've not been touching XWiki Watch for a long time and there's now the XWiki Reader contribution.
Here's what I propose to do:
* Move watch code to xwiki-contrib
* Move documentation found on watch.xwiki.org on an extension page on extensions.xwiki.org.
* Mention on that page that a new project has started: XWiki Reader and point to it
* Remove watch.xwiki.org
* Update home page of xwiki.org to remove watch from there and from the forge page
Here's my +1 (and I'm ok to do it with maybe the help of sergiu for the github move)
Thanks
-Vincent