Hi,
Thomas, JV and I discussed about replacing download pages on xwiki.org with links to our maven repo (for stuff on code.xwiki.org only).
The rationale: Speed up the dev process and make it a failsafe process.
Advantages:
* No need to upload artifacts (which means smaller wiki and faster release process)
* Full history available
* No risk of being not synced with the maven repo (which is the official artifact repository)
* Low-tech solution
http://code.xwiki.org/xwiki/bin/view/Applications/AnnotationsApplication
When you click on download you go to:
http://maven.xwiki.org/releases/org/xwiki/platform/applications/xwiki-appli…
Thomas has already implemented it during the last release. It should have been discussed before but Thomas was in a hurry for the release.
Let us know if you don't agree.
Thanks
-Vincent
Hi all,
I did a small refactoring in the REST module which consisted in
isolating the JAXB model classes in a separate module.
This allows client to use JAXB classes for retrieving XML
representations without dragging in all the core dependencies.
The refactoring consisted in creating an xwiki-rest-model module in
core, moving some files, and update the pom.xml's to make things compile.
Maybe it's risky to commit it now, but if you are ok everything's ready.
I include a diff so that you can check what it looks like.
-Fabio
Hi,
Some time ago I had added the AbstractMockingComponentTestCase class in shared-test. I've refactored it a bit over the week end to make it even easier to use.
The idea is to use a @MockingRequirement annotation in the test case class to get a component instance with all its @Requirement fields injected with mocks.
This makes it easier to test than using the older AbstractComponentTestCase since you don't need to setup component mocks manually.
Here's an example usage:
public class MacroContentTableBlockDataSourceTest extends AbstractMockingComponentTestCase
{
@MockingRequirement
private MacroContentTableBlockDataSource source;
...
Another example:
public class DefaultMacroManagerTest extends AbstractMockingComponentTestCase
{
// Mock all required components except for some for which we want to use the real implementations since they make
// the test easier to write (no need to mock them).
@MockingRequirement(exceptions = { ComponentManager.class, MacroIdFactory.class })
private DefaultMacroManager macroManager;
As you can see in this second example, it's also possible to exclude some @Requirement from being mocked if need be.
I'd like that we agree to use this new test class from now on instead of AbstractComponentTestCase (unless there are cases where it's not usable but please discuss those use cases with me since maybe there are solutions to improve AbstractMockingComponentTestCase).
Here's my +1
Thanks
-Vincent
Festo AG & Co. KG
Lars Hermes
Abteilung IS-PB
BSP Development + User Services
Plieninger Stra?e 50
73760 Ostfildern-Scharnhausen
Deutschland
Telefon +49(711)347-4510
Telefax +49(711)34754-4510
http://www.festo.com
Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen.
This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender.
Rechtsform: Kommanditgesellschaft
Sitz: Esslingen a.N., Registergericht Stuttgart HRA 211583, Umsatzsteuerident-Nummer: DE 145339206
Pers?nlich haftende Gesellschafterin: Festo Management Aktiengesellschaft
Sitz: Wien/?sterreich, Firmenbuchgericht: Handelsgericht Wien, Firmenbuch Nr. FN 303027 d
Vorstand:
Dipl.-Kfm. Alfred Goll
Dr. Claus Jessen
Dr. Ansgar Kriwet
Dr. Eberhard Veit (Vorsitzender)
Dipl.- Kfm. Michael M?lleken
Aufsichtsratsvorsitzender:
Dr. Wilfried Stoll
Hi Devs,
I have almost completed my work on officepreview module and I would like to
discuss about integrating it into main source tree (and release it with
2.4M1). There are a couple of things to discuss:
1. officepreview module have to depend on xwiki-core for the time being
because with current component approach there is no way of determining the
version of an attachment (officepreview module needs to know attachment
version).
2. Need a couple of tests - I'm working on this.
3. Where to place the officepreview module in main source tree.
My initial idea for (3) was to create a
/platform/core/trunk/xwiki-officepreview submodule. However, since
officepreview module depends on officeimporter module, I'm not sure if we
should create a parent module that would host both of these projects.
Another problem lingering in my mind is that with recent changes
xwiki-officeimporter module encapsulates two sub modules - a module capable
of converting documents from one format to another (this is a generic
converter api kind of thing) and another module which is importing office
documents into xwiki specific formats (XDOMOfficeDocumentBuilder,
PresentationBuilder etc.). I'm not sure if these two modules should be
seperated out, but may be that's a separate discussion.
Please let me know your comments about above points.
Thanks.
- Asiri
Hi devs,
Currently we are using some custom 1.0.0RC1 version of jfreechart and
keep using it for only one reason: we are using
org.jfree.chart.plot.Plot#setDataAreaRatio API in the old chart plugin
and we can't find a proper equivalent (i don't even see what this is
doing since it does not change anything in the chart i tried like in
statistics).
My proposal is to simply remove it so that we can move on.
In any case there is a new charting component that should be the one
use and which is already built with recent jfreechart API (we are
pretty lucky that it simply work in such conditions since we
distribute XE with 1.0.0RC1) and if setDataAreaRatio is really related
to en important feature it should be supported by the new component if
not already done.
WDYT ?
Here is my +1
--
Thomas Mortagne
http://www.xwiki.org/xwiki/bin/view/FAQ/#Attachments
Three Questions.
1) how can I sort my FAQ into these two columns ?
2) Can I see the wiki code for this page?
3) How can I get the Author and Modifier at the bottom of the page like
that?
Grant Sales
Security Operations Analyst
ING
20 Washington Ave South
Minneapolis, MN 55401
Tel: 612.342.7889
Fax: 612.342.3428
Cell: 320.761.0966
Email: grant.sales(a)us.ing.com
www.ing-usa.com
ING. Your future. Made easier. (r)
---------------------------------------------------------
NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it.
============================================================================================
The XWiki development team is pleased to announce the release of XWiki
Enterprise 2.4 Milestone 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is second and last milestone of the XWiki Enterprise 2.4 version.
Main changes from XWiki Enterprise 2.4 Milestone 2:
* Objects and classes editor improvements
* New Template-based page creation
* New Invitation Manager application
* New search application improvements
* WYSIWYG Improvements
* JMX Administration Console
* Watchlist improvements
* Script improvements
* Javascript improvements
* Lots of bugs fixes
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24M2
Thanks
- The XWiki dev team
Hi XWiki users,
We have an urgent request, as we need to be able to make a response
TONIGHT (it's not that we did it at the last moment, but that we got the
information very late).
We would like to have XWiki included in the Gartner "Magic Quadrant for
Social Software in the Workplace", which has some tough criterias to get in.
The criterias are to have:
- at least 100000 users (internal to companies, all deployments included)
AND
- at least 4 companies with more than 5000 users (internal to companies)
willing to talk to Gartner about their usage.
While we do have at XWiki SAS companies we work with that we know the
deployment size and that we can contact to see if they are willing to
talk to Gartner, we do need more.
If you have or know of a deployment with more than 1000 users of the
Wiki for INTERNAL USAGE (not public web sites), it would be great if you
can contact us ASAP at marketing(a)xwiki.com
If you have more than 5000 users, please do contact us even more.
Even if you are not sure that you can talk to Gartner please do tell us,
as we need to answer before tonight if we meet the inclusion criterias.
Then there is a follow-up process and we can verify then if talking with
Gartner is possible (we would need at least the deployment acknowledged)
This is very important for XWiki as in can give a lot of visibility to
XWiki and widden the user base thanks to this visibility.
Thanks for your help
Ludovic Dubost
XWiki SAS CEO and XWiki creator
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi devs,
We are already a bit late so i would like to release XE 2.4M1, there
is only some flickering test remaining plus mostly inline style DWG
validation failure.
You can see the started release note at
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24M2
WDYT ?
--
Thomas Mortagne
That's 2.4M2 of course
On Tue, Jun 29, 2010 at 15:47, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> Hi devs,
>
> We are already a bit late so i would like to release XE 2.4M1, there
> is only some flickering test remaining plus mostly inline style DWG
> validation failure.
>
> You can see the started release note at
> http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise24M2
>
> WDYT ?
>
> --
> Thomas Mortagne
>
--
Thomas Mortagne
I believe that in order for a new api to be accepted by the community, it must be more useful and/or easier to use
than the api which it replaces.
The old way of getting a document was this:
$xwiki.getDocument("xwiki:Main.WebHome")
The current way to get a document is this:
$xwiki.getDocument($services.model.createDocumentReference($context.wiki, $space, "WebHome"))
I am quite sure that the user community will choose the former even if it has escaping issues.
Lest one think we can bully the community into choosing the latter by deprecation or removal of methods, recall
the dismal sales of Windows Vista even with the control afforded by the proprietary license and the awesome power
Microsoft wields over the market. The user is the boss, their word is law.
My first proposal is that we move to an easier way to handle document names.
My second proposal is a possible way to do it.
I would like velocity and groovy script authors to be able to give a command like this:
xwiki.getDocument(["Main", "WebHome"]);
or in velocity
$xwiki.getDocument(["Main", "WebHome"])
To make that possible I am proposing we change the reference model as follows:
EntityReference extends List<String>
Each reference has a name which is expressed as a string, it also has a reference to the next node and the last
node. This is a classic example of a LinkedList. The point is that any List<String> is a valid (although reletive)
reference. When a relative reference is passed, it is replaced with a complete reference which is completed using
the document in the context.
As you prepare your -1's please recognize that the community will never go for the current model and almost
anything is better than a rift between the community and the development team. If there are any other ideas of
how to make it that easy, I would be glad to hear them.
Caleb
Hi devs,
I can't execute a XWQL query with different XWikDocument as example below :
*select *userDoc.fullName *from *XWikiDocument as userDoc, XWikiDocument
as doc *where *doc.object(XWiki.ArticleClass).content like '%ludovic%'
and userDoc.object(XWiki.XWikiUsers).email like '%xwiki.com'
*can some one help me ?*
--
Farouk Korteby
Hi... Good to know there are people with common interest in embedding xwiki
to existing project.
Here is my confusion. Please comment if you have idea on this.
I have my J2EE project. It uses JSF, Spring and Hibernate. So I have my own
hibernate.cfg.xml and web.xml and other config files.
Now, I'm trying to add xwiki as a module to my project. Since Xwiki uses
Struts and Hibernate, it also has its own hibernate.cfg.xml and web.xml
files.
How do I integrate these two now?
Can I have both of these in my project and move on?
If I am able to work it out, I think I can move forward. I just learnt the
way how we can delegate the struts action management to the spring
framework.
Regards,
Manish
--
View this message in context: http://xwiki.475771.n2.nabble.com/Embed-xwiki-to-existing-project-tp5070278…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
I would like to start deprecating templates which are no longer used and I think the right way is to make
the deprecated template throw a warning to the logs when it's called.
I am proposing adding a service which does nothing but is deprecated. Templates which we deprecate will
have this call added and then users of said templates will have fair warning that the template will be
removed.
Not knowing what the convention is I will blindly suggest:
$services.velocity.deprecated()
If anyone has a better name, I'd like to hear it.
WDYT?
Caleb
On Jun 28, 2010, at 4:47 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2010-06-28 16:47:46 +0200 (Mon, 28 Jun 2010)
> New Revision: 29792
>
> Modified:
> enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java
> Log:
> [misc] Updated test after modifications in the admin app
>
> Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java
> ===================================================================
> --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java 2010-06-28 14:23:42 UTC (rev 29791)
> +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/administration/elements/AdminTemplatesPage.java 2010-06-28 14:47:46 UTC (rev 29792)
> @@ -36,7 +36,7 @@
> @FindBy(id = "page")
> private WebElement pageInput;
>
> - @FindBy(xpath = "//form/input[@type='submit']")
> + @FindBy(xpath = "//form/div/input[@type='submit']")
Would be better to use an id or name IMO (would make it more deterministic + less maintenance).
Thanks
-Vincent
> private WebElement createButton;
>
> public AdminTemplatesPage()
I would like to remove registeruser.vm because it was once used by the administration app and is now unused.
I would also like to merge register-inline.vm into register.vm and remove c.x.x.web.RegisterAction and move it's
functionality into register.vm so that everything will continue to work without XWiki.Registration.
This will remove 60 lines in one class from xwiki-core and remove/merge away 2 templates making
the code easier to understand for people who don't know the history of it.
WDYT?
Caleb
Hi all,
I am now restarting the work on the gadgets & dashboard project,
documented here
http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however
documentation needs to be slightly revised).
What is done already can be summarized as:
* gadgets are implemented as macros and there is a script to import
google gadgets as xwiki macros,
* also, right now, gadgets are implemented as xwiki macros and can be
used anywhere just like a regular wiki macro, and any wiki macro can be
seen/used as a gadget so **there is no difference between macros and
gadgets** . WDYT about this? should we keep it like that? (A)
* there is a dashboard macro responsible with layouting a gadgets
dashboard, which also provides specific editing features in inline mode
(gadgets can be dragged around, toolboxes for gadgets in the top right)
* there is a minimal macros directory, where one can see all the
existing macros, descriptions, details about the parameters.
* there is an PanelMacro macro, that displays an xwiki panel inside a
document, which can be used to display xwiki panels as gadgets in a
dashboard.
The big picture of the roadmap is that we should:
1/ have a fully working dashboard, that is implement add gadget and edit
gadget settings
2/ implement the main dashboard (Main.Dashboard) as a dashboard and fill
it with the appropriate gadgets by default, and also to add a user
specific dashboard ("My dashboard") where each user can configure
his/her dashboard, and is available to a user from his / her profile or
the user menu
3/ have a nice macros directory where a user can navigate through
existing gadgets and add one to a dashboard
4/ have a "dashboard template", integrated with the document templates
system to easily allow a user to create a dashboard
5/ also, since the xwiki panels can be seen as gadgets / macros, and can
be implemented as such, somewhere in the future a refactoring should be
made to integrate the 2 notions
6/ be able to publish the gadgets in the wiki such that other apps can
integrate this in their content
WDYT about the order above? (B) with the mention that points 5 and 6
could eventually be infinitely postponed.
Also, after points 1 and 2 are implemented, the feature could be
available with xwiki platform and integrated in XE by default. WDYT? (C)
my +1 for (A), (B) and (C).
Happy hacking,
Anca