Hi !
Since a few days, I'm trying to compile the latest source code of xwiki
fetching it from the SVN. Following the tutorial from the xwiki website
first, I encounter major problems (like the TestCase class cannot be found
!) but it resolves as magic a few days after by just updating the code.
My last try was tomorrow, because I wanted to look at the last XWiki GWT
impl. It took 2 hours to resolve problems and have the core module compiled
and installed through maven. Here are the problems I encountered :
- the sablecc plugin from the xwiki-core-query-jpql-parser module give me
some trouble especially having the generated classes available for the test
classes, my solution was to disable tests for this module (I wanted to go as
fast as possible),
- the project xwiki-core-query-xwql had problems in test cases getting
some classes from the previous project : disabling the test was also my
solution,
- the xwiki-core tests fails at this test :
public void testGetLinkedPages10()
{
this.mockXWiki.stubs().method("exists").will(returnValue(true));
this.document
.setContent("[TargetPage][TargetLabel>TargetPage][TargetSpace.TargetPage][TargetLabel>TargetSpace.TargetPage?param=value#anchor][
http://externallink][mailto:mailto]");
List<String> linkedPages =
this.document.getLinkedPages(getContext());
assertEquals(Arrays.asList("Space.TargetPage", "Space.TargetPage",
"TargetSpace.TargetPage",
"TargetSpace.TargetPage"), linkedPages);
}
As you may noticed, I just adapt the assertEquals() line, even if the
expected result is not exact : I want to have the product installed, point.
Then I re-run maven from the root, let it go and went to bed.
This morning I even get another test failed on xwiki-plugin-spacemanager...
:(
What do you suggests me ? Deactivating the tests for all the modules as a
env. var ? I don't want to spend hours just for compiling xwiki... Thx in
advance !
--
Hoani CROSS
Globotraders Tahiti Founder [http://globotraders-tahiti.com]
Dear all,
this is more a RFC than a vote...
Currently the REST subsystem is written using Restlet and its API and
there is a layer based on the XWiki Component manager written by me
that is used to declare and configure resources and components for
providing representations in a more dynamic way.
During the last weekend I spent some time experimenting with the JAX-
RS API and as a test I tried to port the current implementation to
this API.
I was able to do so without too much effort and the result was also a
drastic reduction in code complexity.
In fact all the plumbing I wrote is already handled by the JAX-RS API
implementation. Actually the JAX-RS API provides also more powerful
mechanisms wrt the ones I wrote because it takes into account
representations in responses (GET), representations in requests (PUT
and POST) and exception mappings (i.e., the possibility of capturing
and representing all kind of exceptions, checked or unchecked).
One consequence of these features is that I was able to write methods
to handle requests that use our data model without having to deal with
complicated try/catch blocks for adjusting the response wrt to
exception thrown. Conversions from objects of our data model to
representations and viceversa (text/plain, text/xml, etc.) are handled
by the framework, and exceptions as well.
The problem was the implementation to use. I tried both Jersey and
Restlet and both of them were fine.
Jersey misses some features such as authentication handling (I had to
wrote a basic authentication handler by hand) and is not flexible as
Restlet. Restlet, on the contrary, is very powerful and has a very
good support for JAX-RS but it lacks automatic generation of the WADL
description of the application.
Coming to a conclusion, I would like to switch to JAX-RS + Restlet
because we can have the best of the two worlds. If we need, in fact,
we can still leverage the Restlet API if the JAX-RS is not suitable
for implementing a resource. We will have to give up the WADL support
for the moment, but I don't think this is a big deal with respect to
the gain we have in code maintainability (no more plumbing and easier
resource declaration) and reduced code complexity overall. And WADL
for JAX-RS will be eventually implemented so it's just a question of
time.
Here it is my +1
WDYT?
Regards,
Fabio
Hi Devs,
Currently officeimporter application has three levels of style filtering
options:
1. Strict: Remove all the styles presented in the original document except
for those that can be mapped directly into xwiki syntax
2. None: Keep all the styles (no filtering what so ever)
3. Moderate: Only keep those styles without which the output would be
drastically different from the original document (ex: alignments, image
widths etc.)
As you can see the third option (was my idea) is kind of hard to define and
can be confusing to the user as well. The first too options make a lot of
sense to the user and after discussing with vincent I decided to ask for a
vote to remove it.
Plus this is consistent with the officeimporter wysiwyg plugin which only
allows either to keep all the styles or remove everything.
Also, if we decide to remove the moderate filtering option, we can represent
the options by a checkbox (Filter Styles). Which should be the default
filtering criterion? I'm thinking it should be not to filter any styles so
that the output looks more or less like the original document.
Here's my +1.
WDYT?
Thanks.
Hi,
I have installed the xwiki.war complete all the intructions for Tomcat
Servlet and MySQL Database configuration. But my xwiki is not working
properly ,its giving me the following error.
I have installed the enterprise version of xwiki war. I have gone throught
the forum to see if anyone's got a similar error , but looks like its just
me, just in case if i have missed this error posted by some user and if
there was a solution posted earlier, please point me to that link.
Here is the exception what i get
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Error number 3 in 0: Could not initialize
main XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
root cause
com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main
XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:328)
com.xpn.xwiki.XWiki.getXWiki(XWiki.java:515)
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
note The full stack trace of the root cause is available in the Tomcat logs.
ANd i have installed JDK 1.5.
Can please let help me out with this error.
Thanks,
Nishii
--
View this message in context: http://n2.nabble.com/Could-not-initialize-main-XWiki-context-tp534219p53421…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I would like to release a first version of XWord, but in order to do
that we need to move it out of the sandbox.
Here is what I propose:
* Rename XWord to XOffice since we want to address other Office
applications in the future;
* Move the code in svn to https://svn.xwiki.org/svnroot/xwiki/xoffice
* Rename the jira project to XOFFICE
* Create http://xoffice.xwiki.org
* in the future we should try to integrate msbuild with our hudson
server, to have XOffice under countinuous integration
* release XOffice - version 1.0 M1
Here is my +1
Hi,
We need to allow users to write macros using Velocity and still use
the same mechanism as the new rendering. Basically this means
transforming velocity macros into Rendering Macros. Once this is done
then the velocity macro will be able to be used as standard Rendering
Macros, they'll appear in the new WYSIWYG, etc.
Here's a proposal for doing so:
* Split xwiki-velocity/ module into 2
- xwiki-velocity-engine/ (the one currently in xwiki-velocity)
- xwiki-velocity-macro/ (the new one)
* In xwiki-velocity-macro create a VelocityMacroManager class that
does the following:
- initialize itself at xwiki startup
- create a VelocityMacroClass definition in the wiki if it doesn't
exist
- query the wiki for all objects of type VelocityMacroClass
- for each of them register them dynamically (we can already do
this) as a Rendering Macro
* The VelocityMacroClass has several fields:
- macro name, parameter names, parameters description, macro
description, usage example, velocity content to execute (the macro
content)
* The VelocityMacroManager register itself against the Observation
component to receive notifications whenever a VelocityMacroClass is
modified (added, removed, etc)
* Users will then be able to add velocity macros by simply creating a
new page, adding the VelocityMacroClass in it, fill the values.
* We should also provide a VelocityMacroClassSheet so that the macro
page containing the VelocityMacroClass can display the help for the
macro (self-standing)
The nice thing is that this keeps velocity macro handling in the xwiki-
velocity/ module and makes it completely optional (i.e. the wiki will
still work and there's no ties with this feature elsewhere).
WDYT?
Thanks
-Vincent
http://xwiki.comhttp://xwiki.orghttp://massol.net
Hi devs,
Currently when a document is saved it is rendered with a custom
URLFactory to catch links.
IMO this is wrong because:
- it's impossible to really support generated links since the document
is renderer with a specific context in a specific time etc...
- it could makes saving document real slow if the document contains
big scripts which should not have to worry about that kind of very
crappy rendering
I understand it was easier to do this that way for 1.0 since it was
difficult to parse the document content to find links but the new
rendering does not have this issue anymore. It's now very easy to get
the XDOM and all the links it contains.
So I propose to only take the links found in XDOM before the transformation.
Here is my +1
Thanks,
--
Thomas Mortagne
Hi,
I present myself because I have the intention to participate to the dev of
xwiki.
I hope xwiki give me a multi-user platform. I construct a swing application
with formulaires which modifiates some web pages. My concepts of "content",
"forms" and so on are close xwiki.
My competences are all commons stufs about web, all commons stufs
about net, spring, jdbc, jcr (jackrabbit), swing, freemarker (a little
velocity, but I prefer freemarker), xml, a little j2me, etc.
I work with netbeans, ant, maven, junit, linux (mandriva).
I am in Saint Etienne, France. I work in my very little company (myself, it's
all), and the customers are the ultimate immediate chiefs. I dispose of one or
two hours by days for xwiki.
I suppose the best to begin is to install sources and solve some simple
bugs ?...
(and sorry for my english)
Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location
with you on Google Latitude. You need to sign in to Latitude with a Google
Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to
learn more about Latitude, click the link below.
http://m.google.com/latitude
(c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA.
Terms of Service | Privacy Policy