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
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
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
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
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
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
Hi devs,
I need to make Extension Manager provide a user agent when
communicating with repositories to be a good http citizen but I'm not
sure which user agent to set.
Should it be:
* an Extension Manager repository handler user agent
* an Extension Manager user agent
* an XWiki user agent
* an XWiki platform user agent
WDYT ?
--
Thomas Mortagne
Hi devs
Today we stumbled across, what we think, is a bug. All (at least
almost all) the creation dates are wrong. They are set to the first
occurrence of getDocument() for a specific document and not on first
save(). Usually the difference ist only small (minutes), but there are
cases where the difference are several days.
We suppose that calling getDocument('Test.NotExistingDoc') creates the
document and puts it into the cache with a current timestamp in
creation date. Let's say you work now for an hour before you save the
document, then the creation date would be an hour old even though the
document has just been created.
We always expected the creation date to be the moment of the first
save. Thus we think it's a bug. We came across the problem because we
had someone complaining that a document he created on the 19th was
listed under the ones from the 17th. This could even happen across
users if e.g. there is a link to a not yet existing page. User A
clicks on the link, realizes there is nothing on the page and leaves.
Hours later user B goes to the page and adds content. Now the creation
date of the page would be at an inexplicable time for user B since he
never touched the document until hours after the shown creation date.
We work on 2.7.2 at the moment, but judging by the source code we
think it should be the same in the current version.
To reproduce it create the following script:
#set($newDoc = $xwiki.getDocument('Test.NotExistingDoc'))
$newDoc.getCreationDate()
If you reload several times you see, that the creation date does not
change, even though the document has never been saved. Add a save to
the script:
$newDoc.save()
Now you have a document where creation date and save date of the
version 1.1 do not match.
Should I create a JIRA issue for that? Maybe we could even send you a
git pull request, but you would have to tell us where you want it to
be fixed:
1. In save action. There the creator of the document gets set already.
2. In the store action. We think it would belong there, but are not
sure if this would break something e.g. import or copy
3. Somewhere else
Regards,
Edo
Hi devs,
The 3.4 final release has been delayed almost 3 weeks, for various
reasons, so we need to adjust the planning for 3.5. I propose:
3.4Final: 23 January (this Monday, so in 3 days)
3.5RC1: 6 February (2 weeks)
3.5Final: 13 February (1 week)
WDYT?
I can be the release manager of 3.5 but we need a release manager for
the beginning of the 4.x cycle.
Thanks,
Marius