31 May
2008
31 May
'08
12:46 a.m.
Hello fellow developers,
I followed
http://curriki.xwiki.org/xwiki/bin/view/Main/InstallationInstructions
building with maven 2.0.9 on MacOSX to get curriki running on a
development machine.
- building went very fine
- tried changing things in xwiki.cfg but the indicated property is not
there and xwiki.cfg contains an amount of "undefined" values,
importantly the encoding and default-Skin among others. I could add
each of the missing properties (i.e. the properties used in xwiki.cfg
generation) by adding sibblings of the element
<xwikiCfgEditCommentMandatory>. Similarly, I could add the dependency
on our postgres driver by enriching the dependencies in this pom.xml,
and I could add a few properties which seemed not correct in xwiki.cfg
in the xwikiCfgAdditionalProperties element.
I also activated superadmin... the indicated admin password didn't
work there I think.
- changing the hibernate.cfg.xml I could do as well, but it should be
said not to change the one in target... since it gets overriddent at
every build, but the one in web/src/main/webapp/WEB-INF
At the end I got, with two changed files, a webapp that seems to match
my expectations and which actually started. Ideally, these changes
should happen in an extra file... is there space for this? Something
such as ~/build.properties in maven-1?
After changing catalina.sh to bump memory, I could import the xar
(which I built as well).
There I got stuck because I had to put albatross and not toucan as
default and base skins.
After that I could import the xar and it started looking like curriki.
The log showed an amount of errors which I've ignored thus far.
I concluded with the three manual steps... are they here to stay?
Should I try to update the installation instructions or are there
enhancements to my procedure?
I'm pretty happy with this adventure.... I could, right away, record a
podcast.
paul
1 Jun
1 Jun
10:34 a.m.
Paul Libbrecht wrote:
Hello fellow developers,
I followed
http://curriki.xwiki.org/xwiki/bin/view/Main/InstallationInstructions
building with maven 2.0.9 on MacOSX to get curriki running on a
development machine.
- building went very fine
- tried changing things in xwiki.cfg but the indicated property is not
there and xwiki.cfg contains an amount of "undefined" values,
importantly the encoding and default-Skin among others. I could add
each of the missing properties (i.e. the properties used in xwiki.cfg
generation) by adding sibblings of the element
<xwikiCfgEditCommentMandatory>. Similarly, I could add the dependency
on our postgres driver by enriching the dependencies in this pom.xml,
and I could add a few properties which seemed not correct in xwiki.cfg
in the xwikiCfgAdditionalProperties element.
I also activated superadmin... the indicated admin password didn't
work there I think.
- changing the hibernate.cfg.xml I could do as well, but it should be
said not to change the one in target... since it gets overriddent at
every build, but the one in web/src/main/webapp/WEB-INF
At the end I got, with two changed files, a webapp that seems to match
my expectations and which actually started. Ideally, these changes
should happen in an extra file... is there space for this? Something
such as ~/build.properties in maven-1?
I think there are some steps but this would need the help for our maven
specialists..
Any hint ? The questions is, if I'm right, how to change xwiki.cfg or
hibernate config stuff locally ?
After changing catalina.sh to bump memory, I could
import the xar
(which I built as well).
There I got stuck because I had to put albatross and not toucan as
default and base skins.
After that I could import the xar and it started looking like curriki.
The log showed an amount of errors which I've ignored thus far.
I concluded with the three manual steps... are they here to stay?
Yes... because we
don't have a procedure currently at import for pages
requiring programming rights.
Another step is working around a bug which I could not find the cause for.
Should I try to update the installation instructions or are there
enhancements to my procedure?
Yes definitively.. I would add a new page: "how
to change config params
or the database to mysql or postgres"
I'm pretty happy with this adventure.... I could,
right away, record a
podcast.
paul
------------------------------------------------------------------------
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
2 Jun
2 Jun
11:22 a.m.
Le 01-juin-08 à 10:34, Ludovic Dubost a écrit :
These steps are:
I concluded
with the three manual steps... are they here to stay?
Yes... because we don't
have a procedure currently at import for pages
requiring programming rights.
Another step is working around a bug which I could not find the
cause for. - login and import xar (that's ok to be manual,
although it's true
it'd be nicer automatically)
- run GiveProgRights (this is very similar)
Looks to me like this could be
automated on with a little http set of
dialoges
- set smtp server
Why is that not in xwiki.cfg?
- rename and move files: (org.curriki.gwt.Main to gwt,
and gwt2.js
to gwt/gwt2.js)
These are annoying and run a high risk to be forgotten.
They could also very easily be done with a "post-war" task... does the
notion of postgoal still exist in Maven2?
thanks in advance
paul
11:33 a.m.
On Jun 2, 2008, at 11:22 AM, Paul Libbrecht wrote:
It's optional and what default value would we put? It depends on your
environment and can't be guessed properly.
I have no idea what these are but that's definitely looks like a
problem. The curriki build maintainer should look at this (David? :)).
Just so that it's clear right now we have different build maintainers:
* XE: me
* Watch: Anca
* Workspaces: Jerome
* XEM: Thomas M.
* Curriki: David W.
That said we can all help each other of course ;)
Thanks
-Vincent
Le 01-juin-08 à 10:34, Ludovic Dubost a écrit :
These steps are:
best would simply to fix the pb at the source and allow importing
pages with PR if you have those rights when importing...
I
concluded with the three manual steps... are they here to stay?
Yes... because we
don't have a procedure currently at import for
pages
requiring programming rights.
Another step is working around a bug which I could not find the
cause for. - login and import xar (that's ok to be
manual, although it's true
it'd be nicer automatically)
- run GiveProgRights (this is very similar)
Looks to me like this could be
automated on with a little http set
of dialoges - set smtp
server
Why is that not in xwiki.cfg? - rename and
move files: (org.curriki.gwt.Main to gwt, and gwt2.js
to gwt/gwt2.js)
These are annoying and run a high risk to be forgotten.
They could also very easily be done with a "post-war" task... does
the notion of postgoal still exist in Maven2? 
3 Jun
3 Jun
3:06 a.m.
- rename and move files: (org.curriki.gwt.Main to gwt,
and gwt2.js
to gwt/gwt2.js)
These are annoying and run a high risk to be forgotten.
They could also very easily be done with a "post-war" task... does
the notion of postgoal still exist in Maven2?
9:03 a.m.
On Jun 3, 2008, at 3:06 AM, David Ward wrote:
I have no idea what these are but that's definitely looks like a
problem. The curriki build maintainer should look at this
(David? :)).
If someone could point me at how such a post-war task can be done I
would be glad to get that in there.
No idea on my side, never used GWT and never really used the GWT
plugin either.
- rename and
move files: (org.curriki.gwt.Main to gwt, and gwt2.js
to gwt/gwt2.js)
These are annoying and run a high risk to be forgotten.
They could also very easily be done with a "post-war" task... does
the notion of postgoal still exist in Maven2? The location was determined when xwiki was using Ant
instead of Maven
and I have not found how to pass the appropriate options to the Maven
gwt compiler that would put the compiled code in the right location,
nor how to run a post-compile move of the directory as an alternative.
post-compile move is an "Ant"ish thing and should be avoided if
possible.
One thing you could do is check the sources of the GWT plugin. I do
that frequently with the other plugins and it helps. If that doesn't
work maybe you could ask on the GWT plugin's mailing list/forum.
-Vincent
PS: I'm not even understanding what you're trying to do so I'm just
answering generically here.
10:03 a.m.
Le 03-juin-08 à 09:03, Vincent Massol a écrit :
In a perfect world I agree...
Untill then, something has to be done.
I searched ~/.m2/repository/com/google/gwt/ and there's not single
script in there.
I know ant is old-fashioned but please... a script there would have
made things very easy!
The location
was determined when xwiki was using Ant instead of Maven
and I have not found how to pass the appropriate options to the Maven
gwt compiler that would put the compiled code in the right location,
nor how to run a post-compile move of the directory as an
alternative.
post-compile move is an "Ant"ish thing and should be avoided if
possible. One thing you could do is check the sources of the GWT
plugin. I do
that frequently with the other plugins and it helps. If that doesn't
work maybe you could ask on the GWT plugin's mailing list/forum.
That seems like a non-trivial thing to do, at least their docs do not
show the properties for such settings.
From their documentation page:
http://code.google.com/p/gwt-maven/
(supposedly)
I seem to find that there's a property for maven1 but not for maven2
plugin:
google.webtoolkit.output
PS: I'm not even understanding what you're
trying to do so I'm just
answering generically here.
a post-compile move is what we are trying to do without considering
writing a plugin for such a task!
Following the curriki installation task-list.
http://curriki.xwiki.org/xwiki/bin/view/Main/InstallationInstructions
where there are more of these manual moves which are fully natural
things in a world that is almost perfect.
paul
(wishing curriki went to maven-1.1! ;-))
10:23 a.m.
Hi Paul,
The curriki project is a separate project from the xwiki products (XE,
XEM, etc) and should actually have its own mailing list, SVN
repository, etc (this will be done in the future when an admin can
free up some time). I'm personally NOT a committer on it and I haven't
participated on it except helping initially when someone had to
volunteer to write its build. Since then I haven't touched it and I
don't want to touch it since I'm not part of the project.
FWIW we're using Maven2 for building XWiki Core, XE, XEM, XWiki Watch
and XWS and we're not finding it blocking in any way. And no we don't
have any manual step and it's all automated. So I'd assume the problem
is not with Maven2 itself.
Thanks
-Vincent
On Jun 3, 2008, at 10:03 AM, Paul Libbrecht wrote:
Le 03-juin-08 à 09:03, Vincent Massol a écrit :
In a perfect world I agree...
Untill then, something has to be done.
I searched ~/.m2/repository/com/google/gwt/ and there's not single
script in there.
I know ant is old-fashioned but please... a script there would have
made things very easy!
The
location was determined when xwiki was using Ant instead of
Maven
and I have not found how to pass the appropriate options to the
Maven
gwt compiler that would put the compiled code in the right location,
nor how to run a post-compile move of the directory as an
alternative.
post-compile move is an "Ant"ish thing and should be avoided if
possible. One thing you could do is check the sources of
the GWT plugin. I do
that frequently with the other plugins and it helps. If that doesn't
work maybe you could ask on the GWT plugin's mailing list/forum.
That seems like a non-trivial thing to do, at least their docs do not
show the properties for such settings.
From their documentation page:
http://code.google.com/p/gwt-maven/
(supposedly)
I seem to find that there's a property for maven1 but not for maven2
plugin:
google.webtoolkit.output
PS: I'm not even understanding what
you're trying to do so I'm just
answering generically here.
a post-compile move is what we are trying to do without considering
writing a plugin for such a task!
Following the curriki installation task-list.
http://curriki.xwiki.org/xwiki/bin/view/Main/
InstallationInstructions
where there are more of these manual moves which are fully natural
things in a world that is almost perfect.
paul
(wishing curriki went to maven-1.1! ;-))
11:38 a.m.
Le 03-juin-08 à 10:23, Vincent Massol a écrit :
The curriki project is a separate project from the
xwiki products (XE,
XEM, etc) and should actually have its own mailing list, SVN
repository, etc (this will be done in the future when an admin can
free up some time). I'm personally NOT a committer on it and I haven't
participated on it except helping initially when someone had to
volunteer to write its build. Since then I haven't touched it and I
don't want to touch it since I'm not part of the project.
I this case, I think the devs(a)xwiki.org mailng-list is appropriate
since it's a quite general question about building your own derivative
of XWiki...
Please insist if you think curriki discussion is polluting the XWiki
dev list, this can be easily set-up.
I was more under the impression that, as long as there's the curriki
word in the subject, it is good practice to stay on devs@.
FWIW we're using Maven2 for building XWiki Core,
XE, XEM, XWiki Watch
and XWS and we're not finding it blocking in any way. And no we don't
have any manual step and it's all automated. So I'd assume the problem
is not with Maven2 itself.
Except that you have already an amount of custom plugins made for that.
Basically, ant-scripting, as can be done with the ant-run plugin I
just discovered, pumps into the huge wealth of those ant-tasks that
have been realized.
Such things as a change-file-name is not very specific, but something
that does not yet have a maven plugin but has an ant task (this is a
factor 100) can take advantage of it.
really wishing curriki discussion to leave?
paul
11:53 a.m.
On Jun 3, 2008, at 11:38 AM, Paul Libbrecht wrote:
Not really, these plugins are purely xwiki-specific and nothing generic.
Le 03-juin-08 à 10:23, Vincent Massol a écrit :
Yes right now it is.
The curriki project is a separate project from
the xwiki products
(XE,
XEM, etc) and should actually have its own mailing list, SVN
repository, etc (this will be done in the future when an admin can
free up some time). I'm personally NOT a committer on it and I
haven't
participated on it except helping initially when someone had to
volunteer to write its build. Since then I haven't touched it and I
don't want to touch it since I'm not part of the project.
I this case, I think the devs(a)xwiki.org mailng-list is appropriate
since it's a quite general question about building your own derivative
of XWiki...
Please insist if you think curriki discussion is polluting the XWiki
dev list, this can be easily set-up.
I was more under the impression that, as long as there's the curriki
word in the subject, it is good practice to stay on devs@. FWIW we're
using Maven2 for building XWiki Core, XE, XEM, XWiki Watch
and XWS and we're not finding it blocking in any way. And no we don't
have any manual step and it's all automated. So I'd assume the
problem
is not with Maven2 itself.
Except that you have already an amount of custom plugins made for
that. Basically, ant-scripting, as can be done with the
ant-run plugin I
just discovered, pumps into the huge wealth of those ant-tasks that
have been realized.
Such things as a change-file-name is not very specific, but something
that does not yet have a maven plugin but has an ant task (this is a
factor 100) can take advantage of it.
My only comment was that you should look for a solution using the
existing maven2 plugins before you start considering a work around. As
I said I have no clue what you guys are talking about since I don't
know GWT.
really wishing curriki discussion to leave?
Not really, at least not right now and not before we define a general
strategy for products in general.
Thanks
-Vincent
24 Jun
24 Jun
8:10 a.m.
New subject: [xwiki-devs] [curriki] my attempt at building a development curriki
I have finally uploaded my changed instructions.
Thanks to proof.
paul
PS: curriki list where are you?
Le 31-mai-08 à 00:46, Paul Libbrecht a écrit :
Hello fellow developers,
I followed
http://curriki.xwiki.org/xwiki/bin/view/Main/InstallationInstructions
building with maven 2.0.9 on MacOSX to get curriki running on a
development machine.
- building went very fine
- tried changing things in xwiki.cfg but the indicated property is
not there and xwiki.cfg contains an amount of "undefined" values,
importantly the encoding and default-Skin among others. I could add
each of the missing properties (i.e. the properties used in
xwiki.cfg generation) by adding sibblings of the element
<xwikiCfgEditCommentMandatory>. Similarly, I could add the
dependency on our postgres driver by enriching the dependencies in
this pom.xml, and I could add a few properties which seemed not
correct in xwiki.cfg in the xwikiCfgAdditionalProperties element.
I also activated superadmin... the indicated admin password didn't
work there I think.
- changing the hibernate.cfg.xml I could do as well, but it should
be said not to change the one in target... since it gets overriddent
at every build, but the one in web/src/main/webapp/WEB-INF
At the end I got, with two changed files, a webapp that seems to
match my expectations and which actually started. Ideally, these
changes should happen in an extra file... is there space for this?
Something such as ~/build.properties in maven-1?
After changing catalina.sh to bump memory, I could import the xar
(which I built as well).
There I got stuck because I had to put albatross and not toucan as
default and base skins.
After that I could import the xar and it started looking like curriki.
The log showed an amount of errors which I've ignored thus far.
I concluded with the three manual steps... are they here to stay?
Should I try to update the installation instructions or are there
enhancements to my procedure?
I'm pretty happy with this adventure.... I could, right away, record
a podcast.
paul_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6033
days inactive
6058
days old
10 comments
4 participants
participants (4)
-
David Ward -
Ludovic Dubost -
Paul Libbrecht -
Vincent Massol