[xwiki-devs] my attempt at building a development curriki
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Le 01-juin-08 à 10:34, Ludovic Dubost a écrit :
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.
These steps are:
- 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
On Jun 2, 2008, at 11:22 AM, Paul Libbrecht wrote:
Le 01-juin-08 à 10:34, Ludovic Dubost a écrit :
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.
These steps are:
- 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
best would simply to fix the pb at the source and allow importing pages with PR if you have those rights when importing...
- set smtp server
Why is that not in xwiki.cfg?
It's optional and what default value would we put? It depends on your environment and can't be guessed properly.
- 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?
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
- 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?
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. 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. David --
On Jun 3, 2008, at 3:06 AM, David Ward wrote:
- 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?
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.
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.
Le 03-juin-08 à 09:03, Vincent Massol a écrit :
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.
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!
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! ;-))
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 :
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.
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!
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! ;-))
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 [email protected] 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
On Jun 3, 2008, at 11:38 AM, Paul Libbrecht wrote:
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 [email protected] 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@.
Yes right now it is.
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.
Not really, these plugins are purely xwiki-specific and nothing generic.
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
David Ward -
Ludovic Dubost -
Paul Libbrecht -
Vincent Massol