The XWiki development team is pleased to announce the release of
XEclipse 1.0.1
You can find it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiEclipse
XEclipse is an Eclipse plug-in that allows the user to interact with
an XWiki server directly from within the Eclipse IDE. It comes in two
flavors: as an Eclipse plugin that can be directly integrated in the
Eclipse IDE or as a standalone RCP application.
This release is mostly a maintenance release that fixes some serious
bugs that prevented XEclipse version 1.0 to work correctly.
Main changes from 1.0:
* Solved XMLRPC issues when connecting to XWiki version 1.2
* Solved problems in XWiki Explorer structure visualization.
* Added some minor user interface improvements (e.g., page loading
progress bars).
Thanks
-The XWiki dev team
Hi,
As previously proposed, today (Friday 30th) is the planned day for the
first 1.2 Release Candidate. There are still a few issues remaining
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010…
which I'd like to see fixed before noon (CET), when I'll start the
release process.
There will probably be another RC shortly, as there are a few more tasks
that should be fixed for improving the stability of the 1.2 version of
XE, but there should be a final 1.2 before Javapolis.
Thanks,
Sergiu and my +1
Hi,
I'd like to move the current trunk (1.2-SNAPSHOT) to a branch right
after the release planned for today, given the fact that after the first
RC no new features or major changes in the code can be committed. The
only projects that need to be branched are platform-core, platform-web
and products-enterprise, as the others will not see major modifications
in less than two weeks. However, if someone does need to commit new code
in a dependency for XE/platform, we can create a branch on the fly.
Thanks,
Sergiu and my +1
If the answer is yes, then I propose that we modify the
XWiki.getUserClass() method to create a XWiki.XWikiUsers class that
has the "usertype" property by default.
I think the notion of simple/advanced user could be one that is
generic enough to be a core feature.
I'm curious to know what you think.
Thanks
-Vincent
Dear XWikiers,
I'd like to propose voting Anca Luca as a XWatch committer.
Anca has submitted several good patches for XWiki Watch. (see
http://tinyurl.com/2x3psb) She writes clean code and shows a strong focus
on design and separation of concerns. I propose she now commit her own
patches on XWatch!
Here's my +1 for Anca.
Note: For full disclosure, Anca is working for XPertNet, the company
behind the creation of XWiki. FWIW, out of the 26 committers
(http://www.xwiki.org/xwiki/bin/view/Community/HallOfFame), 9 are working
for XPertNet. Note that the XWiki project is driven as a meritocratic
project (trying to follow the Apache rules as much as possible) and thus
anyone can become a committer (see
http://www.xwiki.org/xwiki/bin/view/Community/Committership). The more the
merrier!
Regards,
Jérôme.
Hi all,
Having xwiki document with no extension in the files names is a real
mess for subversion and IDEs like Eclipse and IntelliJ IDEA and it
will also be very useful in any editor that takes extension to
determine the content or simply for most OS Explorers/Finders.
As the XWiki maven xar plugin now support files with any name when
creating the xar package (see
http://jira.xwiki.org/jira/browse/XTOOLS-19) I propose to add .xml
extension to exported document files names.
Import document with any names is already supported by xwiki core
importer plugin since at least svn1387 (October 2006) and I think
since it's creation so it seems it will not break older version
import.
--
Thomas Mortagne
Hi,
Here's my list of what remains to be done to release XE 1.2RC1:
* fix the MINOR EDIT exception that happens from time to time on
xwiki.org: http://jira.xwiki.org/jira/browse/XWIKI-1879
* continue looking at xwiki.org logs and fix exceptions that appear
* commit the stats patch submitted by Marius http://jira.xwiki.org/jira/browse/XWIKI-1845
* fix the XHTML validation issues discovered by the build
* test the stats feature on xwiki.org (enable stats with Raffaello and
monitor xwiki.org's performances)
* test the watchlist feature on xwiki.org (configure the smtp server
with Raffaello and try the feature)
If you know of other important issues for XE 1.2RC1 that cannot wait
for later please let us know.
Thanks
-Vincent
Hi Sergiu,
We need to discuss this since this is starting something new that
we've never discussed.
How do you plan to distribute the s5 application? I don't see how to
do that with a web module or do you mean that this web module will
generate a zip that the user will manually unzip in his xwiki webapp?
Should we distribute 2 files (XAR+ZIP) or one file (a single zip
containing both)?
Also this raises the question of plugins which I've started to discuss
some time ago: should they go in applications or stay in plugins/?
Thanks
-Vincent
On Nov 26, 2007, at 6:59 PM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2007-11-26 18:59:12 +0100 (Mon, 26 Nov 2007)
> New Revision: 6086
>
> Added:
> xwiki-platform/xwiki-applications/trunk/s5/wiki/
> xwiki-platform/xwiki-applications/trunk/s5/wiki/pom.xml
> xwiki-platform/xwiki-applications/trunk/s5/wiki/src/
> xwiki-platform/xwiki-applications/trunk/s5/wiki/src/main/
> Removed:
> xwiki-platform/xwiki-applications/trunk/s5/src/
> xwiki-platform/xwiki-applications/trunk/s5/wiki/src/main/
> Modified:
> xwiki-platform/xwiki-applications/trunk/s5/pom.xml
> Log:
> Create a submodule for the wiki pages, as this application should
> also contain velocity templates and skin files that will go in a web
> module.
>
[snip]
Hello,
I was wondering about the code that is by default in a class sheet - when
you create a class with the class wizard.
The class sheet has code to display all properties of one object of the
concerned class. To display each property, you use the display() method
which accesses a property through its name. Now imagine you have a page with
objects of different classes, and some of the classes have same-named
attributes. The respective class sheets are all included in the page. Then
the display() method, when used, will be confused.
How about replacing the Velocity call
$doc.display($prop.getName())
by this one :
$doc.getObject("YourClassSpace.YourClass").get($prop.getName())
? What do you think ?
--
Jean-Vivien MAURICE
Elève Ingénieur Informatique et Gestion, Polytech'Montpellier (ISIM)
E-mail : jean.vivien.maurice(a)gmail.com
Tél. : 0046 7 62 33 20 46
Skype : jean.vivien
Hi,
Since we're nearing the final XE 1.2 release I'd like that we vote on
each of the following:
1) Once Panels app 1.2 is released, separate the versioning of the
Panels app from the versioning of XE/Platform, i.e. next version will
be 1.3 without milestones. Same as for the other apps/plugins.
2) Create a branch now for XE/Platform/Panels 1.2RC1 so that work can
start on trunk for Platform 1.3M1 and XE 1.3M1.
3) Don't do a XE/PF/Panels 1.1.3 release and instead move XEM and
other products to XE/PF/Panels 1.2 final (since it's going to be
released in less than a month). This will also allow to have only 2
branches to manage: the trunk and the branch from 2). This also means
that we should probably release a XEM 1.0 quickly (that'll use PF
1.1.2) and start working on XEM 1.1 on trunk which will use PF 1.2.
Here's my +1 to all 3 items above.
Thanks
-Vincent