I tried to build xwiki from sources. Since the build system is powered by
maven it shouldn't be a problem ;-)
I've added all xwiki repositories and the google web toolkit repositories as
described in http://dev.xwiki.org/xwiki/bin/view/Community/Building.
But I cannot get the maven-googlewebtoolkit2-plugin artifact. The build
stops with the following error message:
Reason: POM 'com.totsp.gwt:maven-googlewebtoolkit2-plugin' not found in
repository: Unable to download the artifact from any repository
com.totsp.gwt:maven-googlewebtoolkit2-plugin:pom:1.5.3
If you point your webbrowser to the google maven repository at
http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/ there is only the new
2.0 version inside the maven-2 repository structure. The old 1.5.3 version
is only accessible in the maven-1 repository structure.
Well, to cut a long story short the question is: How can I resolve this
specific artifact?
Thanks in advance
Firvin
--
View this message in context: http://n2.nabble.com/Building-XWiki-from-sources-tp1351482p1351482.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Devs,
As you might know, to complete the integration of xwiki-webdav component in
the XWiki-UI (that is to allow users to edit attachments via webdav), we
needed some support from FoXWiki (on FireFox). Now comes the problem of
where to host FoXWiki.
NOTE : We need a download link to FoXWiki that we can embed inside one of
our js files that will trigger an automatic installation. So, we must host
FoXWiki somewhere before providing webdav functionalities in xwiki UI.
So, we have two options :
1. Host FoXWiki in addons.mozilla.org :-
With this option, we don't need to worry about automatic updates (it is
automatically handled) and there is a nice web interface that allows us to
manage various versions. But the downside is, each version need to spend
some time on the sandbox (of addons.mozilla.org) before it becomes public -
some users need review and rate it.
Ex : https://addons.mozilla.org/en-US/firefox/addon/2358
2. In xwiki.org :-
With this option we have to handle everything manually and we need to
provide an update url (which has to be an https url) which will contain
information about updates. The good side of this is that there is no waiting
with this approach.
Any ideas about which approach to be taken ?
Thanks.
- Asiri
Hi,
We'll be two XWiki guys in the valley Monday <-> Wednesday. Anybody
interested in a meetup on monday or tuesday evening ?
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Dear all,
I am taking advantage of the weekend in order to work on XEclipse's
release. However I've just found a problem on the server side. While
doing some tests using all XWiki versions, when I try to connect to
XWiki 1.6 I get this exception: http://pastebin.com/m49b769bd
Other XWiki versions work fine.
Tests seems to be fine on hudson so I don't know why I am getting this
exception when testing against the packaged hsqldb.zip version.
Any clue?
-Fabio
The XWiki development team is pleased to announce the release of XWiki
Workspaces 1.1.1
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is a bug-fix release. It does correct the following bugs :
* XWS-176 - Cannot access history of a wiki page when only "reader"
* XWS-183 - When creating a space, sample wiki page and blog post last modification date is not updated
* XWS-184 - Events from archived spaces do appear on dashboards and are clickables
* XWS-188 - When we attach a new image in an existing gallery, in the activity stream the message is "created" when it should be "updated"
* XWS-190 - On dashboards, the links to photo gallery images lead to an empty page
For more information see the Release Notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces111
Regards
-The XWiki dev team
hello,
I finally found the way of using JSX with Velocity variables :)
I was defining the custom Velocity variables in the doc containing the JSX
object and it doesn't work. These variables must be defined inside the JSX
object code because the Velocity context is specific to this code
interpretation.
But in my case, I really need to use $xwiki.jsx.use() with some custom
parameters since my javascript requires this customization to work.
Basic velocity context with $xwiki, $doc etc... is too blank to help me.
I think being able to pass some custom parameters to JSX could be really
practical in many cases (as explained in the
http://dev.xwiki.org/xwiki/bin/view/Design/SkinExtensions)
Don't see very big security issues but you may find some :)
I propose to manage this using simple HTTP parameters while calling
jsx.use() in order to provision the $request velocity variable with custom
parameters.
For example:
$xwiki.jsx.use("myJSXdoc?param1=value1¶m2=value2¶m3=value3")
Then in myJSXdoc, you create a JSX object with code looking like:
#set($param1 = $request.get("param1"))
#set($param2 = $request.get("param2"))
#set($param3 = $request.get("param3"))
doit()
{
dosomething("${param1}");
dosomething2("${param2}");
dosomething3("${param3}");
}
The code patch is really simple.
Just a modification of:
public String getLink(String documentName, XWikiContext context) in
skinx.jsSkinExtensionPlugin in order to create a link such as:
<script src="
/xwiki/bin/jsx/myspace/myJSXdoc?param1=value1¶m2=value2¶m3=value3"
type="text/javascript">
regards
Pascal
Hello,
has anybody the same slow and choppy scrolling issue under Firefox3 with
XWiki?
Apparently this is linked to the fixed CSS background for the header menu...
It doesn't appear on all hardware/OS configurations but lots of people
complain about it.
As XWiki uses a fixed background by default, I preferred warning you because
this is really a pain using xwiki under FF3 on my computer :)
(if you remove the "fixed" CSS field, it works betteeeeeeeer)
regards
Pascal
Hi devs,
I'd like to apply http://jira.xwiki.org/jira/browse/XWIKI-2667 , but one
thing I'd like to change is the format of the log messages. The current
patch uses String.format, but I prefer MessageFormat, as it is more
expressive, and it is already used by the localization tool.
So:
1. We use String.format, because:
- it is "simpler" (some say)
- it is familiar to C/C++ programmers
- it is a bit more customizable at the finer level
- the code is already written
2. We use MessageFormat, because:
- it is already used for localization strings
- it is more expressive (I really like the "choice" format)
- it is apparently less customizable, but it uses good defaults (I'd
rather specify that I want a "long" date format than a "DD MMMM HH:mm:ss
z" format)
- the changes are minimal
- I for one prefer this syntax, rather than the old printf one.
My +1 for option 2.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
I am trying to enable https requests for xwiki, that is, xwiki is able to handle https request thru' its xmlrpc APIs. So I am working on xmlrpc using swizzle-confluence-1.1-20070908-xwiki.jar file to enable https requests.
Is it possible to get the source of this jar file from somewhere so that i can customize the code as per my requirements?
thanx
ac
Regards,
Amit Chawla